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(54) System for controlling the distribution and use of composite digital works 



(57) A system (or controlling use and dislribulion of 
composite digital works. A digital work is comprised of 
a description part (700) and a content part. The descrip- 
tion part contains control information (or the composite 
digital work. The content part stores the actual digital 
data comprising the composite digital work. The de- 
scription part (700) is logically organized in an acycHc 
structure, e.g. a tree structure. For a composite digital 
work each node of the acyclic structure represents an 
individual digital work or some distribution interest in the 
composite digital work. A node In the acyclic structure 
is comprised of an klentifier (701 ] of the individual work. 



usage rights (704) for the individual digital work and a 
pointer (705.706) to the digital work. Composite digital 
works are stored in r^ositories, A reposilory has two 
primary operating modes, a sender mode and a request- 
er mode. When operating in a server mode, the repos- 
itory is responding to requests to access digital works. 
When operathg in requester mode, the repository 
questing access to a digital work, A repository will proc- 
ess each request to access a composite digital work by 
examining the usage rights (or each individual digital 
work lound in the description part of the composite dig- 
ital work. 
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Description 

Tlie present invention relates to tlie field of distribution and usage rights enforcement for digitally encoded works. 
A fundamental issue facing the publishing and information industries as they consider electronic publishing Is how 

s to prevent the unauthorized and unaccounted distribution or usage of electronically published materials. Electronically 
published materials are typically distributed in a digital form and recreated on a computer based system having the 
capability to recreate the materials. Audio and video recordings, software, books and multimedia works are all being 
electronically published Companies in these industries receive royalties for each accounted for delivery of th"e mate- 
rials, e.g. the sale of an audio CD at a retail outlet. Any unaccounted distribution of a work results In an unpaid royalty 

10 (e.g. copying the audio recording CD to another digital medium) 

The ease in which electronically published works can be "perfectly" reproduced and distributed is a major concern. 
The transmission of digital works over networks is commonplace. One such widely used network is the Internet. The 
Internet is a widespread network facility by whicJi conputer users in many universities, corporations and government 
entitles communicate and trade Ideas and infornatlon. Computer bulletin boards lound on the Internet and commercial 

'3 networks such as CompuServand Prodigy allow for the posting and retrieving of digital Infomiation. Information sen/ices 
such as Dialog and LEXIS/NEXIS provide databases of current information on a wide variety ol topics. Another factor 
which will exacerbate the situation is the devekjpment and expansion of the Nattonal Inlonmation Infrastructure (the 
Nil). It is anticipated that, as the IMII grows, the transmission ol digital works over networks will increase many times 
over. It would be desirable to uUHze the Nil for dislributton ol digital works without the fear of widespread unauthorized 

20 copying. 

The most straightfonward way to curb unaccounted distribution is to prevent unauthorized copying and transmis- 
sion. For existing materials that are distributed in digital form, various safeguards are used. In the case ol software, 
copy protection schemes whteh limit the nunriber of copies that can be made or which corrupt the output when copying 
Is detected have been employed. Another scheme causes software to become disabled after a predetermined period 

25 ol time has lapsed. A technique used for workstation based software is to require that a special hardware device must 
be present on the workstatton in order for the software to nin, e.g., see US-A-4 .932,054 entitled 'Method and Apparatus 
for Protecting Computer Software Utilizing Coded Filter Network in Conjunctkin with an Active Coded Hardware Device. 
' Such devices are provided with the software and are commonly referred to as dongles. 

Yet another scheme is to distribute software, but which requires a 'key' to enable its use. This is employed In 

30 distribution schemes where 'demos' ol the software are provided on a medium along with the entire product. The 
demos can be freely used, but in order to use the actual product, the key must be purchased. These schemes do not 
hinder copying of the software once the key is initially purchased. 

It is an object of the present invention to provide an improved system and method for controlling the use and 
distribution of digital works. 

3S The invention acconlingly provides a system and method as claimed in the accompanying claims. 

A system for controlling use and distribution of composite digital works is disclosed. A composite digital work is 
comprised of one or more individual digital worlds. An individual digital work is any written, aural, graphical or video 
based work that has been translated to or created in a digital form, and which can be recreated using suitable rendering 
means such as software programs. A foUer containing one or more digital works may be treated as a composite digital 

to work. The present invention allows the omer of an individual digital work to attach usage rights to their work which 
are honored when the individual digital work Is incorporated into a composite digital work. The usage rights for the 
work define how the individual digital work may be used and distributed. The aggregation of the usage rights of the 
individual digital works of a composite digital work, as well as usage rights attached to the composite digital work as 
a whole define how the composite digital work may be used and distributed. 

« A digital work is comprised of a description part and a content part. The descriptkw part contains control infomiaiion 
for the composite digital work. The content part stores the actual digital data cbmprising the composite digital work. 
The description part Is kjgically organized in an acycUc stniciure (e.g. a tree structure.) For a composite digital work 
each node of the acyclic stnjcture represents an individual digital work or some distributkm interest in the digilal work. 
A node in the acyclic stnJCture is comprised of an klentlfier of the individual work, usage rights for the Individual digital 

50 work and a pointer to the digital work. In this representation, the description part may naturally be stored separately 
on a separate medium from the content part. 

Composite digilal works are stored in repositories. A repository is comprised of a storage means lor storing a digital 
work and its attached usage rights, an external interface for receiving and transmitting data, a processor and a ckxsk. 
A repository has two primary operating modes, a sen/er mode and a requester mode. When c^erating in a sewer 

ss mode, the repository is responding to requests to accessdigltal works. When operating in requester mode, the repos- 
itory is requesting access to a digital wortc. A repository will process each request to access a composite digital work 
by examining the usage rights lor each indivklual dig'ital work found in the description part. Access is granted il the 
composite digital work If access to each of the individual digital works can be granted. Alternatively, if access to all the 
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individual digital works cannot be granted, partial access can bs gtanled only to those individual digital works which 
grant access. 

A system and method in accordance with the invention will now be descrbed. by way of example, with reference 
to the accompanying drawings, in which 
s Figure 1 is a flowcliart Uluslraling a simple instantiation of the operation of the currently preferred embodiment of 

the present invention. 

Figure 2 is a block diagram yiustrating the various repository types and the repository transaction flow between 
them in the currently preferred embodiment of the present invention. 

Figure 3 is a block diagram of a repository coupled with a credit server in the currently preferred embodiment of 
10 the present invention. 

Figures 4a and 4b are examples of rendering systems as may be utilized in the currently preferred embodiment 
of the present invention. 

Figure 5 illustrates a contents file layout for a digital work as may be utilized in the currently preferred embodiment 
of the present invention. 

IS Figure 6 illustrates a contents file layout for an individual digital work of the digital work of Figure 5 as may be 
utilized in the currently preferred embodiment of the present invention. 

Figure 7 illustrates the components of a description bkx:k of the currently preferred embodiment ol the present 
Invention. 

Figure 8 illustrates a description tree for the contents tile layout ol the digital work illustrated in Figure 5. 
20 Figure 9 illustrates a portion of a description tree corresponding to the individual digital work illustrated in Figure 6. 

Figure 1 0 illustrates a layout for the rights portion of a description bkxkas may be utilized in the currently preferred 
embodiment ol the present invention. 

Figure 11 is a description tree wherein certain d-btocks have PRINT usage rights and is used to illustrate "strfct" 
and 'lenient" rules for resolving usage rights conflicts. 
25 Figure 12 is a block diagram of the hardware components of a repository as arc utilized in the currently preferred 

embodiment of the present invention. 

Figure 1 3 is a block diagram ol the functional (logical) components of a repository as are utilized In the currently 
preferred embodiment of the present invention. 

Figure 14 is diagram illustrating the basic components of a usage right in the currently preferred embodiment of 
so the present invention. 

Rgure 15 lists the usage rights grammar of the currently preferred embodiment of the present invention. 

Figure 16 Is a ftowchart iSustrating the steps of certificate delivery, hotlisl ctiecking and perfomrance testing as 
performed in a registratkm transaction as may be performed in the currently preferred embodiment of the present 
invention. 

as Figure 1 7 is a flowchart illustrating the steps of sesskjn information exchange and clock synchn^nization as may 
be performed in the currently preferred embodiment of the present inventksn, after each repository in the registration 
transaction has successfully completed the steps described In Figure 16. 

Figure 18 is a (kjwchart illustrating the basic flow (or a usage transaction, including the common opening and 
closing step, as may be performed in the currently preferred embodiment of the present invention. 

'to Figure 1 9 is a state diagram of sen/er and client repositories in accordance with a transport protocol fol lowed when 
moving a digital work from the senrer to the client repositories, as may be performed h the currently preferred embod- 
iment of the present invention. 

OVERVIEW 

A system for controlling use and distrBxjtion of digital works Is disckised. The present invention is directed to 
supporting commercial transactions Involving digital works. 

Herein the terms "digital work", *work' and 'conlenf refer to any work lhat has been reduced to a digital repre- 
sentation. This would include any audio, video, text, or multimedia work and any accompanying interpreter (e.g. solt- 
ware) that may be j-equired lor recreating the work. The tenm composite work refers to a digital work comprised of a 
collection of other digital works. The terni 'usage rights" or "rights" is a term which refers to rights granted to a recipient 
ol a digital work. Generally, these rights define how a digital work can be used and H it can be further distributed. Each 
usage right may have one or mac specified conditions which must be satisfied before the right may be exorcised. 

Figure 1 is a high level flowchart omitting various details but whfch demonstrates the basic operation of the present 
ss invention. Referring to Figure 1, a creator creates a digital work, step 101. The creator will then determine appropriate 
usage rights and fees, attach them to the digital work, and store them in Repositoty 1 , step 102. The detennination ol 
appropriate usage rights and fees will depend on varksus economic factors. The digital work remains securely in Re- 
pository 1 until a request tor access is received. The request for access begins with a session initiation by another 
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repository. Here a Repository 2 initiates a session with Repository 1 , step 103. As will be described in greater detail 
below, this session Initiation includes steps which helps to insure that the respective repositories are trustworthy As- 
suming that a session can be established. Repository 2 may then request access to the Digital V\lbrk for a stated 
purpose, step 104. The purpose may be, (or exaniple. lo print the digital work or to obtain a copy of the digital work. 

s The purpose will coffespond to a specific usage right. In any event. Repository 1 checks the usage rights associated 
with the digital work to determhe If the access to the digital work may be granted, step 105. The check of the usage 
rights essentially involves a determination of whether a right associated with the access request has been attached to 
the digital work and it all conditions associated with the right are satisfied. If the access is denied, repositoiy 1 terminates 
the session with an error message, step 106. If access is granted, repository 1 transmits the digital work to repository 

TO 2, step 107. Once the digital work has been transmitted to repository 2, repository 1 and 2 each generate billing infor- 
mation for the access whnh Is transmitted to a credit sen/er, step 108. Such double billing reporting is done to Insure 
against attempts lo circumvent the billing process. 

Figure 2 illustrates the basic Interactions between repository types In the present invention. As will become apparent 
from Figure 2, the various repository types will setve different functions. It is fundamental that repositories will share 

IS a core set of functionality which will enable secure and trusted communications. Referring lo Figure 2. a repository 
201 represents the general instance of a repository. The repository 201 has two modes of operation; a server mode 
and a requester mode. When in the server mode, the repository will be receiving and processing access requests to 
digital works. When in the requester mode, the repository will be initiating requests to access digital v/orks. Repository 
201 is general in the sense that its primary purpose is as an exchange medium for digital works. During the course of 

20 operation, the repository 201 may communicate with a plurality of other repositories, namely authorization repository 
202, rendering repository 203 and master repository 204. Corronunication between repositories occurs utilizing a re- 
pository transaction protocol 205. 

Commun Ication with an authorization repository 202 may occur vrhen a digital work being accessed has a condition 
requiring an authorization. Conceptually, an authorization is a digital certificate such that possession of the certificate 
Is required to gain access to the digital work. An authorization is itsotf a digital work that can be moved between 
repositories and subjected to fees and usage rights conditions. An authorizatnn may be required by both repositories 
involved in an access to a digital work. 

Communication with a rendering repository 203 occurs In connection with the rendering of a digital work. As will 
be described In greater detail below, a rendering repository Is coupled with a rendering device (e.g. a printer device) ' 

30 to comprise a rendering system. 

Ccmmuntcation witha master repository 205 occurs h connection with obtaining an kjentincatkm certificate. Iden- 
tiiicalion certificates are the means by which a repositoiy is identilied as 'trustworthy*. The use d kJentincatlon certif- 
icates is described below with respect to the registratkxt transaction. 

Figure 3 illustrates the repository 201 coupled to a credit server 301. The credit sender 301 is a device which 

35 accumulates billing information for the repository 201. The credit server 301 communicates with repository 201 via 
billing transactions 302 to record billing transactions. Billing transactions are reported to a billing clearinghouse 303 
by the credit server 301 on a periodic basis. The credit server 301 communicates to the billing clearinghouse 303 via 
clearinghouse transactions 304. The clearinghouse transactions 304 enable a secure and encrypted transmission of 
information to the billing clearinghouse 303. 

40 

RENDERING SYSTEtVIS 

A rendering system is generally defined as a system comprising a repository and a rendering device which can 
render a digital work into its desired form. Examples ol a rendering system may be a computer system, a digital audio 

4S system, or a printer. A rendering system has the same security features as a repositoiy. The coupling ol a rendering 
repository with the rendering device may occur In a manner suitable (or the type o( rendering device. 

Figure 4a illustrates a printer as an example of a rendering system. Referring to Figure 4, printer system 401 has 
contained therein a printer repositoiy 402 and a print devtee 403. It should be noted that the the dashed line defining 
printer system 40 1 defines a secure system boundary. Communications within the boundary are assumed to be secure. 

so Depending on the security level, the boundary also represents a barrier intended to provide physical integrity The 
printer repository 402 is an instantiation of the rendering repository 205 of Figure 2. The printer repository 402 will In 
some instances contain an ephemeral copy of a digital work whksh remains until it is printed out by the print engine 
403. In other instances, the printer repositoiy 402 may contan digital works such as fonts, which will remain and can 
be billed based on use. This design assures that all communication lines between printers and printirig devices are 

ss encrypted, unless they are within a physically secure boundaiy. This design feature eliminates a potential 'fault* point 
through which the digital work couM be improperly obtained. The printer device 403 represents the printer components 
used to create the printed output. 

Also illustrated in Figure 4a is the repository 404. The repository 404 is coupled to the printer repositoiy 402. The 
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repository 404 represents an external repository which contains digital vrorks. 

Figure 4b is an example of a computer system as a rendering system. A computer system may constitute a •multi- 
function* device since il may execute digital works (e.g. software programs) and display digilal works (e.g. a digitized 
photograph). Logically, each rendering device can be viewed as havhg its own repository, although only one physical 
repository is needed. Referring to Figure 4b. a computer system 410 has contained therein a display/execution repos- 
itory 4 1 1 . The display/execution repository 41 1 is coupled to display device. 41 2 and execution device 4 1 3. The dashed 
box surrounding the computer system 410 represents a security boundary within which communications are assumed 
to be secure. The display/execution repository 411 is lurlher coupled to a credit sewer 414 to report any fees to be 
billed for access to a digital work and a repository 415 lor accessing digital works stored therein. 

STRUCTURE OF DIGITAL WORKS 

Usage rights are attached directly to digital works. Thus, it is important to understandihe structure of a digital work 
The structure of a digital work, in particular composite digital works, may be naturally organized into an acyclic structure 
such as a hierarchy. For example, a magazine has various articles and photographs which may have been created 
and are owned by different persons. Each of the articles and photographs may represent a node in a hierarchical 
structure. Consequently, controls, i.e. usage rights, may be placed on each node by the creator. By enabling control 
and fee billing to be associated with each node, a creator of a work can be assured that the rights and fees are not 
circumvented. 

In the currently prelerred embodiment, the file informatton for a digital work Is divided into two Hies: a 'contenls" 
file and a "description tree" file. From the perspective of a repository, the "contents" file is a stream of addressaWa 
bytes whose formal depends completely on the interpreter used to play, display or print the digital woA. The descriptton 
tree file makes il possible to examine the rights and fees for a work wHhout reference to the content of the digilal work, 
1 1 should be noted that the lanm description tree as used herein refers to any type ol acyclic structure used to represent 
the relationship bolween the various components of a digital work. 

Figure 5 illustrates the layout ol a contents file. Referring to Figure 5. a digital work is comprised of story A 510, 
advertisement 511, story B 512 and story C 513. It is assumed that the digital work is stored starting at a relative 
address of 0. Each of the parts of the digilal work are stored linearly so that story A 510 is stored at approximately 
addresses 0-30.000, advertisement 511 at addresses 30.00 1-40.000. story B 512 at addresses 40.001-60 000 and 
story C 51 3 at addresses 60.001 -85K The detail of story A 510 is illustrated in Figure 6. Referring to Figure 6, Uie 
story A 510 is further broken down to show text 614 stored at address 0-1500. soldier photo 615 at addresses 
1501-10.000. graphfes 616 stored at addresses 10.001 -25.000 and sidebar 617 stored address 25,001-30.000. Note 
that the data in the contents file may be compressed (for saving storage) or encrypted (for security). 

From Figures 5 and 6 it is readily observed that a digital work can be represented by its component parts as a 
hierarchy. The description tree for a digilal work is comprised of a set of related descriptor blocks (d-btocks). The 
contents of each d-block is described with respect to Figure 7. Refen-hg to Figure 7. a d-Wock TOO hcludes an identifier 
701 which is a unique identifier lor the work in the repository, a starting address 702 providing the start address of the 
first byte ol the work, a length 703 giving the number of bytes in the work, a rights portion 704 wherein the granted 
usage rights and their slatus data are maintained, a parent pointer 705 for pointing to a parent d-bkxk and child pornters 
706 for poiriting to the child d-blooks. In the currently preferred embodiment, the identifier 701 has two parts. The first 
part is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned 
to the work upon creatton. The rights portkan 704 will contain a data structure, such as a look-up table. v4ierein the 
various information associated with a right is maintained The information required by the respective usage rights is 
described in more detail below. D -blocks lorm a strict hierarchy. The top d-block ol a work has no parent; all other d- 
blocks have one parent. The relationship of usage rights between parent and child d-blocks and how conflicts are 
resolved is described betow. 

A special type ol d-block is a "sheir d-block. A shell d-bkjck adds no new content beyond the content of its parts. 
A shell d-block Is used to add rights and fee informatkm. typically by distributors of digital works. 

Figure 8 illustrates a description tree for the digital work of Figure 5. Referring to Rgure 8, a top d-bkxk 820 for 
the digilal work points to the various stories and advertisements contained therein. Here, the top d^kxk 820 points to 
d-block 321 (representing story A 51 0). d-block 822 (representing the advertisement 511 ), d-block 823 (representing 
story B 512) and and d-bkxk 824 (representing story C 513). 

The portion of the description tree for Story A 510 Is illustrated in Figure 9. 0-block 925 represents text 614, d- 
block 926 represents photo 615. d-block 927 represents graphfes 616 by and d-block 928 represents sidebar 617. 

The rights portton 704 of a descriptor block is further illustrated in Figure 10. Figure 10 illustrates a structure which 
is repeated in the rights portion 704 for each right. Referring to Figure 10. each right will have a right code field 1050 
and status information field 1052. The right code field 1050 will contain a unique code assigned to a right. The status 
intomnation field 1.052 will contain information relating lothe state of a right and the digital work. Such informatton is 
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indicated below in Table 1 . The rights as stored in the rights portion 704 may typically be in numerical order based on 
the right code. 



TABLE 1 



DIGITAL WORK STATE INFORMATION 


Property 


Value 


Use 


Copies-in-Use 


Number 


A counter ol Ihe number o1 copies ol a work thai are in use. Incremented when 
another copy Is used; decremented when use is completed. 


Loan-Period 


Time-Units 


Indicator of Ihe maximum number of time-units that a document can be loaned 


Leaner-Copy 


Boolean 


Indicator that the cuaent work is a loaned out copy of an authorized digital work. 


Remaining-Time 


Time-Units 


Indicator of the remaining lime of use on a metered document right. 


Documeni-Descr 


String 


A string containing various identifying information about a document The exact 
format of this is not specified, but it can Include information such as a publisher 
name, author name, ISBN number, and soon. 


Revenue-Owner 


RO-Descr 


A handle identifying a revenue owner lor a digital work. This is used for reporting 
usage fees. 


Publication-Date 


Date-Descr 


The date that ihe (figital work was published. 


History-list 


History-Rec 


A list of events recording the repostories and dates for operations that copy, 
transfer, backup, or restore a digital work. 



The approach for representing digtai works by separating description data Irom content assumes that parts of a 
file are contiguous but lakes no position on the actual representation ol content. In particular, it is neutral to the question 
of whether content representation may lake an object oriented approach. It would be natural to represent content as 
objects. In principle. It may be convenient to have content objects that include the billing structure and rights information 
that is represented in the d-blocks. Such variations in the design of the representation are possible and are viable 
alternatives but may introduce processing overhead, e.g. the interpretation of the objects. 

Digital works are stored in a repository as part of a hierarchical file system. Folders (also termed directories and 
sub-directories) contain the d'gital works as well as other folders. Digital works and folders In a folder are ordered in 
alphabetk»l order. The digital works are typed to reflect how the tiles are used. Usage rights can be attached to folders 
so that Ihe folder itself Is treated as a digital worit. Access to the folder would then be handled in the same fashion as 
any other digital work As will be described in more detail below, the contents of the folder are subject to theirown rights. 
Moreover, file management rights may be attached to the (older which define how foMer contents can be managed. 

ATTACHING USAGE RIGHTS TO A DIGITAL WORK 

II is fundamental to the present inventbn that the usage rights are treated as part of the digital work. As the digital 
work is distributed, the scope of the granted usage rights will remain Ihe same or may be narrowed. For example, when 
a digital work is transferred from a document sereer to a repositoiy, the usage rights may include the right to loan a 
copy for a predetermined perkxl of time (called the original rights). When the reposftoiy k>ans out a copy of the digital 
work, the usage rights in the taaner copy (called the next set ol rights) could be set to prohibit any further rights lo loan 
out the copy. The basic idea is that one cannot grant more rights than they have. 

The attachment of usage rights into a digital work may occur in a variety of ways. If the usage rights will be the 
same for an entire digital work, they couM be attached when the digital work is processed for deposit in the digital work 
server. In the case ol a digital work having different usage rights (or the various components, this can be done as the 
digital work is being created. An authoring tool or digital work assembling tool could be utilized whch provides for an 
automated process of attaching the usage rights. 

As will be described below, when a digital work is copied, transferred or loaned, a 'next set of rights' can be 
specified. The'next set of rights* will be attached to the digital wori< as it is transported. 

Resolving Conflicting Rights 

Because each part of a digital vrark may have its own usage rights, there will be instances where the rights of a 



6 



EP 0715 246 A1 



■contained part* are different from its parent or conlaher part. As a result, conflict rules must be established to dictate 
wtien and how a right may be exercised. The hierarchical structure ol a digital work facilitates the enforcement of such 
rules. A 'strict' rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned 
for the part, for ancestor d-blocks containing the part and for all descendeni d-blocks. By sanctioned, it is meant that 
s (1 ) each ol the respective parts must have the right, arid (2) any conditk>ns for exercising the right are satislied. 

It also possible to implement the present invention using a more lenient rule. In the more lenient rule, access to 
the part may be enabled to the descendent parts which have the right, but access is denied to the descendents which 
do not. 

An example of applying both the strict rule and lenienl is illustrated with reference to Figure 11 . Referring to Figure 
10 11, a root d-block 1101 has child d-blocks 1102-1105. In this case, root d-block represents a magazine, and each ol 
the child d-blocks 1102-1105 represent articles in the magazine. Suppose that a request is made to PRINT the digital 
work represented by root d-block 1101 wherein the strct rule is followed. The rights tor the root d-block 1101 and child 
d-blocks 1 102-1 1 05 are then examined. Root d-block 1 101 and child d-bkx:ks 1 102 and 1 105 have been granted PRINT 
riojits. Child d-block 1 103 has not been granted PRINT rigtws and child d-block 1104 has PRINT rights conditioned on 
>5 payment ol a usage fee. 

Under the strk:t rule the PRINT right cannot be exercised because the child d-btex;k does not have the PRINT right. 
Under the lenient rule, the result wouki be ditterent. The digital works represented by child d-blocks 1102 and 1105 
could be printed and the digital work represented by d-block 1104 could be printed so long as the usage lee is paid. 
Only the digital work represented by d-bkx:k 1 1 03 could not be printed. This same result would be accomplished under 
the strict rule if the requests were directed to each of the Individual digital works. 

The present invention supports various combinations of allowing and disaltowing access. Moreover, as will be 
described below, the usage rights grammar permits the owner of a digital work to specify If constraints may be imposed 
on the work by a container part The msiner in which digital works may be sanctioned because of usage rights conflicts 
- would be implementation specific and wouM depend on the nature of the digital works. 

2S 

REPOSITORIES 

In the description of Figure 2, it was Indicated that repositories come in various forms. All repositories provide a 
core set of servkses for the transmisskxi ol digital works. The manner in which digital wori(s are exchanged is the basis 
30 for aP transaction between repositories. The various repository types differ in the ultimate functions that they perform. 
Repositories may be devices themselves, or they may be incorporated into other systems. An example is the rendering 
repository 203 of Figure 2, 

A repository will have associated wKh II a repository klentifier. Typically, Ihe repository identifier would be a unique 
number assigned to the repository at the lime of manufacture. Each repository will also be classified as being In a 
3S particular security class. Certain communicatians and transactions nnay be conditK>ned on a repository being in a 
particular security class. The various security classes are described in greater detail below 

As a prerequisite to operation, a repository will require possession of an identification certificate. Identification 
certificates are encrypted to prevent forgery and are issued by a Master repository. A master repository plays the role 
ol an authorization agent to enable repositories to receive digital works. Identification certificates must be updated on 
40 a periodic basis. Identification certificates are described in greater detail bek>w with respect to the registration trans- 
action. 

A repository has both a hardware and functional embodiment. The functk)nal embodiment is typically software 
executing on the hardware embodiment. AAematively. the functional embodiment may be embedded in the hardware 
embodiment such as an Applicatnn Specilic Integrated Circuit (ASIC) chip. 

"fs The hardv/are embodiment of a repositoiy will be enclosed in a secure housing which if compromised, may cause 
the repository to be disabled. The basic components of the hardware embodiment ol a repository are described with 
reference to Figure 1 2. Referring to Figure 12. a repository is comprised of a processing means 1 200, storage system 
1 207, clock 1 205 and external inieriace 1 206. The processing means 1 200 is comprised of a processor element 1 20 1 
and processor memory 1 202. The processing means 1201 provides controller, repository transaction and usage rights 

so transaction functions for the repository. Various functions in the operation of the repository such as decryption and/or 
decompresskjn of digital works and transaction messages are also perfonned by the processing means 1200. The 
processor element 1201 may be a mieroprocessof or other suitable computing component. The processor memory 
1 202 would typtoally be further comprised of Read Only Memories (ROM) and Random Access Memories (RAM). Such 
memories would contain the software instructions utilized by the processor element 1201 in performing the functions 

55 of the repository. 

The storage system 1 207 is furihercomprised of descriptor storage 1 203 and content storage 1 204. The description 
tree storage 1203 will store the description tree for the digital work and the content storage will store the associated 
content. The description tree storage 1203 and content storage 1 204 need not be of the same type of storage medium. 
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nor are they necessarily on the same physical device. So (or example, the descriptor storage 1 203 may be stored on 
a solid state storage (for rapid retrieval ol the description tree information), while the content storage 1 204 may be on 
a high capacity storage such as an optical disk. 

The clock 1205 is used to time-starrp various linne based conditions (or usage rights or (or metering usage fees 
s which may be associated with the digital works. The ctock 1205 will have an uninterruptable power supply, e.g. a 
battery, in order to maintain the integrity ol the lime-stamps. The external inter(ace means 1 206 provides (or the signal 
connection to other repositories and to a credit server. The external interlace means 1 206 provides (or the exchange 
of signals via such standard interfaces such as RS-232 or Personal Computer Manufacturers Card Industry Association 
(PCMCIA) standards, or FDDI. The external interface means 1206 may also provide network connectivily 
ifl The functional embodiment of a repository Is described with reference to Figure 13. Referring to Figure 13, the 
functional embodiment is comprised of an operating system 1301, core repository services 1302, usage transaction 
handlers 1303, repository specific functions, 1304 and a user hterface 1305. The operating system 1X1 is specific 
to the repository and would typically depend on the type of processor being used. The operating system 1301 would 
also provide the basic sen'ices (or controlling and interlacing between the basic components of the repository. 

the core repository services 1302 comprise a set o( functions required by each and every repository. T^ie core 
repository services 1302 include the session initiation transactions which are defined in greater detail below. This set 
of services also includes a generic ticket agent whKh is used to "punch" a digital ticket and a generic authoriratton 
server for processing authorization specifications. Digital tickets and authorizations are specific mechanisms (or con- 
trolling the distribution and use of digital works and are described In more detail below. Note that coupled to the core 
20 repository services are a plurality of ideniilication certificates 1 306. The kJentificalion certificales 1 306 are required to 
enable Uie use ol the repository. 

The usage transactions handlers 1 303 comprise (unctlonality for processing access requests to digital works and 
for billing fees based on access. The usage transactions supported will be differeni for each repository type. For ex- 
ample, it may not be necessary for some repositories to handle access requests (or digital works. 
25 The repository specific functionality 1304 comprises functionality that is unique fo a repository. For example, the 
master repositoiy has special (unctlonality (or issuing digiUI certificates and maintaining encryption keys. The lepositoiy 
specific (unctnnality 1 304 would Include the user lnter(ace implementation for the repository 

Repository Security CIssses 

30 

For some digital works the losses caused by any indivWual instance of unauthorized copying is insignificant and 
the chief economic concern lies in assuring the convenience oi access and low-overhead billing. In such cases, simple 
and inexpensive handheld repositories and network-based workstations may be suitable repositories, even though the 
measures and guarantees ot security are modest. 

3S At the other extreme, some digital works such as a digital copy of a first run movie or a bearer bond or stock 
certifnate woutel be of very high value so that it is prudent to employ caution and (airly elaborate security measures to 
ensure that they are not copied or lorged. A repository suitable for holding such a digital work couW have elaborate 
measures for ensuring physical integrity and for verifying authorization before use. 

By arranging a universal protocol, all kinds o( repositories can communfcate with each other in principle. However, 

10 creators of some works will want to specHy that their works will only be transferred to repositories whose level of security 
is high enough. For this reason, document repositories have a ranking system for classes and levels ol security The 
security classes in the currently preferred embodiment are described in Table 2. 



TABLE 2 



REPOSITORY SECURITY LEVELS 


Level 


Description of Security 


0 


Open system. Document transmlsston is unenciypted. No diglial:Certlflcate is required (or kJenlification. 
The security of the system depends mostty on userhonesty, since only modest knowledge may be needed 
to circumvent the security measures. The repository has no provisbns (or preventing unauthorized 
programs from running and accessing or copyingfiles. The system does not prevent the use of removable 
storage and does not encrypt stored files. 


1 


Minimal security Like the previous class except that stored files are minimally encrypted, including ones 
on removable storage. 



Continuation ol the Table on the next page 
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TABLE 2 (continued) 





Level 


Description of Securhy 


£ 


2 


Basic security. Like ihe previous class except that special tools and knowledge are required to 
compromise the programming, the contents of the repository, or the slate of the clock. All digital 
communications are encrypted. A digital certificate Is provided as Ideniificalion. Medium level encryption 
is used. Repository identification number is untorgeable. 


15 


3 


Genorai security. Like Iho previous class plus the rcquiroment of special tools are needed to compromise 
the physical integrity of the repository and that modest encryption is used on all transmissions. Password 
protection is required to use the local user inteface. the digital clock system cannot be reset without 
authorization. No works would be stored on removable storage. When executing works as programs, it 
runs them in their own address space and does not give them direct access to any file storage or other 
meiTwry containing system code or works. Then can access works only through the trattsmission 
transaction protocol. 




4 


Like the previous class except that high level encryption Is used on all communicatnns. Sensors are 
used to record attempts at physical and electronic tampering. After such tampering, the repository will 
not perform other transactions until It has.reported such tampering to a designated server. 


.0 
2S 


5 


Like the previous class except that If the physical or digital attempts at tampering exceed some preset 
thresholds that threaten the physical Integrity of the repository or the integrity ol digital and cryptographic 
barriers, then the repository will save only documentdoscription records of history but will eraseor destroy 
any digital identifiers that could be misused if released to an unscrupulous parly It also modifies any 
certificates ol authenticity to indicate that the physical system has been compromised. It also erases the 
contents of designated documents. 


6 


Like the prevtousclass except that the repository will attempt wireless communication to report tampering 
and will employ noisy alanns. 


30 


10 


This would correspond to a very high level of security This senrer would maintain constant 
communications to remote security systems reporting transactions, sensor readings, and attempts to 
circumvent security.. 



The characterization of security levels described in Table 2 is not bitended to be fixed. More important is the idea 
of having different security levels for different repositories. It is anticipated that new security classes and requirements 
^ will evolve according to social situations and changes In technology. 

Repository User Interface 

A user interface is broadly defined as the mechanism by which a user interacts with a repository in order to invoke 
transactions to gain access to a digital work, or exercise usage rights. As descrOnd above, a repository may be em- 
bodied in various forms. The user intorfaco for a repository will differ depending on the particular embodiment. The 
user interface may be a graphical user interface having icons representing the digital works and the various transactions 
that may be perlonned. The user interlace may be a generated dialog in which a user is prompted for information. 

The user interface itself need not be part ol the repository. As a repository may be embedded in some other device. 
^ J the user interface may merely be a part ol the device in which the repository is embedded. For example, the repository 
could be embedded in a 'card' that is inserted into an available skit in a computer system. The user biterface may be 
a combination of a display, keyboard, cursor control device and software executing on the computer system. 

At a minimum, the user interface must permit a user to input information such as access requests and alpha 
numeric data and provide feedback as to transaction status. The user interface win then cause the repository to initiate 
the suitable transactkms to service the request. Other facets of a particular user interface will depend on the functionality 
that a repository will provide. 



CREDIT SERVERS 

In the present invention, fees may be associated with the exercise of a right. The requirement for payment of fees 
Is described with each version of a usage right in the usage rights language. The recording and reporting of such fees 
is pertormed by the credit sen/er. One of the capabilities enabled by associating fees with rights is the possibility of 
supporting a wide range of charging models. The simplest model, used by conventional software, is that there is a 
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single fee at the time of purchase, after which the purchaser obtains unlimited rights to use the worl< as often and for 
as long as he or she wants. Alternative models, include metered use and variable lees. A single work can have different 
fees lor different uses. For example, viewing a photograph on a display could have different lees than making a hardcopy 
or including it in a newly created work. A key to these allemative charging models is to have a low overhead means 

s of establishing fees and accounting for credit on these transactions. 

A credit server is a computational system that reliably authorizes and records these transactions so that fees are 
billed and paid. The credit ser\'er reports fees to a billing clearinghouse. The billing clearinghouse manages the financial 
transactions as they occur. As a result, bills may be generated and accounts reconciled. Preferably, the credit server 
would store the fee transactions and periodically communicate via a network with the billing clearinghouse lor recon- 

10 ciliatlon. In such an embodiment, communications with the billing clearinghouse woukJ be encrypted for integrity and 
security reasons. In another embodiment, the credit sewer acts as a "debit card" where transactions occur in "real- 
time" against a user account. 

A credit server is comprised of memoiy, a processng means, a clock, and interface means for coupling to a re- 
pository and a financial institution (e.g. a modem). The credit server will also need to have security and authentication 

*s functionality. These elements are essentially the same elements as those of a repository. Thus, a single device can 
be both a repository and a credit server, provided that it Itas the appropriate processing elements for carrying out the 
corresponding functions and protocols. Typically, however, a credit sewer would be a card-sized system in the pos- 
session of the owner ol the credit. The credit server is coupled to a repository and would Interact via financial trans- 
actions as described below. Interactions with a financial bisiltution may occur via protocols established by the financial 

20 institutions themselves. 

In the currently preferred embodiment credit servers associated with both the server and the repository report the 
financial transaction to the billing clearinghouse. For example, when a digital work Is copied by one repository to another 
for a fee. credit servers coupled to each of the repositories will report the transaction to the billing clearinghouse. This 
is desirable in that it insures that a transactkin will be accounted for in the event of some break in the communication 

ss between a credit server and the billing clearinghouse. However, some implementations may embody only a single 
credit server reporting the transaction to minimize transactron processing at the risk of tosing some transacttons. 

USAGE RIGHTS LANGUAGE 

30 The present invention uses statements in a high level "usage rights language" to define rights associated with 

digital works and their parts. Usage rights statements are interpreted by repositories and are used to determine what 
t ransactlons can be successfully carried out for a digital work and also to determine parameters for those transactions. 
For example, sentences in the language determine whether a given digital work can be copied, when and how it can 
be used, and what fees (if any) are to be charged lor that use. Once the usage rights statements are generated, they 

35 are encoded in a suitable form for accessing during the processing of transactions. 

Defining usage rights in terms of a language in combinalion with the hierarchical representation of a digital work 
enables the support of a wide variety of distribution and lee schemes. An example is the ability to attach multiple 
versions of a right to a work. So a creator may attach a PRINT right to make S copies for $10.00 and a PRINT right to 
make unlimited copies lor $100.00. A purchaser may then choose which option best fits his needs. Another example 

40 is that rights and fees are additive. So in the case of a composite work, the rights and fees of each of the components 
works is used in determining the rights and fees for the work as a whole. 

The basic contents of a right are illustrated in Figure 14. Referring to Figurje 14. a right 1450 has a transactional 
component 1 451 and a specifications component 1 452. A right 1450 has a label (e.g. COPY or PRI NT) which indicates 
the use or distribution privileges that are embodied by the right. The transactional component 1451 corresponds to a 
particular way in which a digital work may be used or distributed. The transactional component 1451 is typically em- 
bodied in software instructions in a repository which implement the use or disinbutfon privileges for the right. The 
specifications components 1452 are used to speclfycondittons which must be satisfied prkirtothe right being exercised 
or to designate various transaction related parameters. In the currently preferred embodiment, these specifications 
include copy count 1453. Fees and Incentives 1454, Time 1455, Access and Security 1456 and Control 1457. Each 

so of these specifications will be described in greater detail betow with respect to the language grammar elements. 

The usage rights language Is based on the grammar descrilwd below. A grammar is a convenient means for 
defining valid sequence of symbols for a language. In describing the grammar the notation "(al b Ic]' is used to indicate 
distinct choices among allcrnatives. In this example, a sentence can have either an "a", "b* or "c". It must include 
exactly one of them. The braces {) are used to indicate optional items. Note that brackets, bars and braces are used 

5£ to describe the language of usage rights sentences but do not appear in actual sentences in the language. 

In contrast, parentheses are part of the usage rights language. Parentheses are used to group items together In 
lists. The notation (x*) is used to indicate a variable length list, that is. a list containing one or more Hems of type x. 
The not8tk»i (x)* is used to indicate a variable number of lists containing x. 
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Keywords in the grammar are words followed by colons. Keywords are a common and very special case in the 
language. They are often used to indicate a single value, typically an identifier. In many cases, the keyword and the 
parameter are entirely optional. When a keyword Is given, it often lakes a single identifier as its value. In some cases, 
the keyword takes a list ol identifiers. 
s In the usage rights language, time is specified in an hours:minutes:seconds (or hh:mm:ss) representation. Time 

zone indicators, e.g. PDT lor Pacific Daylight Time, may also be specified. Dates are represented as year/ month/day 
(or YYYY/MMM/DD), Note that these time and date representations may specify moments in time or units of time 
Money units are specified in terms of dollars. 

Finally, in the usage rights language, various things" will need to interact with each other. For example, an instance 
JO of a usage right may specify a bank account, a digital ticket, etc.. Such things need to be identified and are specified 
herein using the suffix "-ID." 

The Usage Rights Grammar is listed in its entirety in Figure 15 and is described betow. 

Grammar element 1501 'Dlgitaf Work Rights: = (Rights*)" define the digital work rights as a set of rights. The 
set ol rights attachied to a digital work define how that digital work may be transferred, used, performed or played. A 
'5 set of rights will attach to the entire digital work and in the case of compound digital works, each of the components of 
the digital work. The usage rights ol components of a digital may be dilferenl. 

Grammar element 1502 "Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec} {Access-Spec} 
{Fe«-Spec})" enumerates the content of a right. Each usage right must specify a right code. Each right may also 
optionally specify conditions which must be satisfied before the right can be exercised. These conditions are copy 
20 count, control, lime, access and fee conditions. In the currently preferred embodiment, lor the optional elemenls, the 
following defaults apply: copy count equals 1. no time limit on the use of the right, no access tests or a security level 
required to use the right and no fee is required. These conditions will each be described in greater detail below. 

It is important to note that a digital work may have multiple versions of a right, each having the same right code. 
The multiple version would provide alternative conditions and fees for accessing the digital work. 
25 Grammar element 1 503 "Right-Code : a Rendor-Code I Transport-Code I File-Managemenl-Codel Derivative- 

Works- Code Configuration-Code" distinguishes each ol the specific rights inlo a particular right type (although each 
right is identified by distinct right codes). In this way, the grannmar provides a catalog ol possible rights that can be 
associated with parts ol digital works. In the lollowing, rights are divided into categories for convenience In describing 
ihem. 

30 Grammar element 1504 'Render-Code : = [Play : {Player: Player-ID}IPrlnt- {Printer: Printer-ID}]" lists a cat- 

egory of rights all involving the making of ephemeral, transitory, or non-digital copies of the digital work. After use the 

copies are erased. 

• Play A process of rendering or performing a digital wort* on some processor. This includes such things as playing 
3S digital movies, playing digital music, playing a video game, running a computer program, or displaying a 

document on a display. 

• Print To render the work in a medium that is not further protected by usage rights, such as printing on paper. 

Grammar element 1505 "Transport-Code := [Copy I Transfer I Loan {Remalnlng-Rlghts: Next-Set-of-Rights}] 
40 {(Next-Copy-Rights: Next-Set of Rights)}" lists a category of rights involving the making ol persistent, usable copies 
of the digital work on other repositories. The optional Next-Copy-Righls determine the rights on the work after it is 
transported. If this is not specified, then the rights on the transported copy are the same as on the original. The c^tional 
Remaining-Rights specify the rights thai remain with a digital work when it is loaned out. If this is not speciHed, then 
the default is that no rights can be exercised when it is loaned out 

• Copy Make a new copy ol a work 

• Transler Moving a work from one repository to another. 

• Loan Temporarily toaning a copy to another lepositoiy for a specified period ol time. 

a> Grammar element 1506 'File^Management-Code : a Backup {Back-Up-Gopy-RIghts: Next-Set -of Rlghts)l 
Restore I Delete I Folder I Directory {Name:Hide-Local I Hide-Remote}{Parts:Hide-LoeallHlde-Remote}* lists a 
category of rights involving operations for file riianagement, such as the making of tiackup copies to protect the copy 
owner against catastrophic equipment failure. 

Many software licenses and also copyright law give a copy owner the right to make backup copies to protect against 
catastrophic failure of equipment. However, the making of uncontrolled backup copies Is inherently at odds with the 
ability to control usage, since an uncontrolled backup copy can be kept and then restored even after the authorized 
copy was sold. 

The File management rights enable the making and restoring of backup copies in a way that respects usage rights. 
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honoring the requirements of both the copy ovmer and the rights grantor and revenue owner. Backup cofxes of work 
descriptions (including usage rights and fee data) can be sent under appropriate protocol and usage rights control to 
other document repositories of sufficiently high security. Further rights permit orgariization of digital works into folders 
which themselves are treated as digital works and whose contents may be "hidden" from a party seeking to determine 
s the contents of a repository. 

• Backup To make a backup copy of a digital work as prolectwn against media failure. 

• Restore To restore a backup copy o( a digital work. 
•Delete To delete or erase a copy of a digital work. 

70 • Folder To create and name folders, and to move files and folders between folders. 

• Directory To hide a folder or its contents. 

Grammar element 1S07 "Derlvative-Works-Code : [ExtractlEmbedlEdlt{Process: Process-ID}] {Next-Copy- 
Rights : Next-Set-of Rights)" lists a category of rights involving the use of a digital work to create new works. 

• Extract To remove a portion ol a work, for the purposes ol creating a new work. 

• Embed To include a work in an existing work. 

• Edit To alter a digital work by copying, seleciing and modifying portions of an existing digital work. 

so Grammar element 1508 "Configuration-Code : = Install I Unlnstall" lists a category ol rights (or installing and 

uninstalling software on a repository (typically a tendering repository.) This wouki typteally occur for the installation of 
a new type of player within the rendering repository. 

• Install: To install new software on a repository. 

2* •Uninslall: To remove existing software from a repository. 

Grammar element 1509 "Next-Set-of-Rlghts : = {{Add: Set-Of-Rights)} {{Delete: Set-Of-Rights)} {(Replace: 
Set-Of-Rights)} {(Keep: Set-Of-Rtghts)]* defines how rights are carried fomvard for a copy of a digital work. If the 
Next-Copy-Rights is not specified, the rights for the next copy are the same as those of the current copy. Othenwisa. 
30 the set of rights (or the next copy can be specified. Versions of rights after Add: are added to the current set of rights! 
Rights after Delete: are deleted from the current set of rights. If only right codes are listed after Delete:, then all versions 
of rights with those codes are deleted. Verstons of rights after Replace: subsume all versions of rights of the same type 
in the current set of rights. 

If Remaining-Rights is not specified, then there are no rights for the original after all Loan copies are loaned out. 
3s If Remaining-Rights is specified, then the Keep: token can be used to simplify the expression of what rights to keep 
behind. A list of right codes following keep means that all of the verskxis of those listed rghls are kept in the remaining 
copy. This specification can be overridden by subsequent Delete: or Replace: specincalfcms. 

Copy Count SpeeKeatlon 

40 

For various transactions, if may be desirable to provide some limit as to the number of "copies* of the work which 
may be exercised simultaneously for the right For example, it may be desirable to limit the number of copies of a digital 
work that may be loaned out at a time or viewed at a time. 

Grammar element 1510 "Copy-Count : ^(Copies: positive-Integer 1 0 1 unllmfted)" provides a condition which 
defines the number of "copies'of a work subject to the right. A copy count can be 0. a fixed number, or unlimited. The 
copy-count is associated with each right, as opposed to there being just a single copy-count for the digital work. The 
Copy-Count fora right is decremented each time that a right Is exercised. When the Copy-Count equals zero, the right 
can no longer be exercised. If the Copy-Count is not specified, the default is one. 

^0 Control Specification 

Rights and fees depend in general on rights granted by the creator as well as further restrictions imposed by later 
distributors. Control specificattons deal with intotactkms between tho creators and their distributors governing tho im- 
position of further restrictions and fees. For example, a distributor ol a digital work may not want an end consumer of 
« a digital work to add fees or othenwise profit by commercially exploiting the purchased digital work. 

Grammar element 1511 'Controt-Spec : = (Control: {Restrictable I Unrestrictable) {Unchargeable I Charge- 
able})" provides a condition to specify the effect of usage rights and fees of parents on the exercise of the right. A 
digital work is restrictable if higher level d-blocks can impose further reslrictrans (lime specfficattons and access spec- 
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ilications) on the right. It is unreslriclable i( no further restrictions can be imposed. The default setting is restrictable. 
A right is unchargeable if no mote lees can be Imposed on the use of the right, it is chargeable If more tees can be 
Imposed. The default is chargeable. 

S Time Speelfleatlon 

li is often desirable to assign a slart dale or specify some duration as to when a right may be exercised. Grammar 
element 1512 "Tirtie-Spec : = ({Fixed-Interval I Sliding-lnterval I Meter-Time} Until: Explration-Date)° provides 
for specification of time conditions on the exercise of a right. Rights may be granted for a specified time. Different kinds 

10 of lime specifications are appropriate for different kinds of rights. Some rights may be exercised during a fixed and 
predetermined duration. Some rights may be exercised for an inten/al that starts the first time that the right is invoked 
by some iransaction. Some rights may be exercised or are charged according to some kind of metered lime, v/hich 
may be split into separate intervals. For example, a ri^t lo view a picture for an hour might be split into six ten minute 
viewings or four fifteen minute viewings or twenty three mhute viewings. 

'5 The terms "time" and 'date" are used synonymously to refer to a moment in time. There are several kinds of time 
speciticalions. Each specification represents some limitation on the times over which the usage right applies. The 
Expiration-Date specifies the nm>ment at which the usage right ends. For example, if the Expiration-Date Is *Jan 1, 
1 995,' then the right ends ai the first moment of 1995. If the Explratlon-Oate is specified as 'forever', then the rights 
are Interpreted as continuing without end. II only an expitalion date is given, then the right can be exercised as often 

20 as desired until the expiration dale. 

Grammar element 1513 *Rxe<>-lnterval : s From: Start-Time* is used to define a predetermined inten/al that 
runs from the start lime to the expiration dale. 

Grammar element 1514 'Sliding-lnterval: s Interval: Use-Duration* Is used to define an indeterminate (or 
'open') start time 1 1 sets limits on a continuous period of lime over which the contents are accessible. The period starts 

2S on the first access and onds after the duration has passed or the expiration date is reached, whichever comes first. 
For example, if the right gives 10 hours of continuous access, the use-duration would begin when the first access was 
made and end 10 hours later. 

Grammar element 1515 'Meter-Time : = Time-Remaining: Remaining-Use* is used to define a 'meter time,' 
that is, a measure of the time that the right is actually exorcised. It differs from the Sliding-lnterval specification in that 

30 the lime that the digital work Is In use need not be continuous. For example, if the rights guarantee three days of access, 
those days could be spread out over a month. With this specification, the rights can be exercised until the meter time 
is exhausted or the expiration date is reached, whichever comes first. 

Remaln'mg-Use: = Time-Unit 
35 Slart-Time: = Time-Unit 

Use-Duration: = Time-Unit 

All of the time specifications include time-unit specifications in their ultimate instantiation. 

40 Security Class and Authorization SpeeUieatlon 

The present inventbn provides for various security mechanisms to be introduced into a distribution or use scheme. 
Grammar element 1516 *Access-Spec : s ({SC: Security-Class} {Authorization: Authorization-ID*} {Other-Au- 
thorization: Authorization-ID*} {Ticket: Ticket-IO})' provkles a means for restrteting access and transmission. Ac- 
4S cess specifications can specify a required security class for a repositoiy to exercise a right or a required authorization 
test that must be satisfied. 

The keyword "SC:" is used to specily a minimum security level for the repositories Involved in the access. If 'SC: 
' .is not specified, the lowest security level is acceptable. 

The optional 'Authorization:* keyword Is used to specify required authorizations on the same repositoiy as the 
so work. The optional 'Other-Authorization:* keyword is used to specify required authorizations on the other repository 
in the tiansaction. 

The optional "Ticket:* keyword specifies the identity ofatreket required for the transacton. Atransaction involving 
digital tickets must locate an appropriate digital ticket agent who can 'punch' or otherwise validate the ticket before 
the Iransaction can proceed. Tickets are described in greater detail below. 
55 In a transaction involving a repositoiy and a document server, some usage rights may require that the repositoiy 
have a panlcular authorization, that the senmr have some authorization, or that both repositories iiave (possibly dif- 
ferent) authorizations. Authorizations themselves are digital works (hereinafter referred to as an authorization object) 
that can be moved between repositories in the same manner as other digital works. Their copying and transferring is 
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subject to ihe same rights and lees as other digital works. A repository is said to have an authorization if that author- 
ization object is contained within the repository. ; 

In some cases, an authorization may be required from a source other than the document server and reposiloiy. 
An authorization object referenced by an Authorization-ID can contain digital address information to be used to set up 
a communications link between a repository and the authorization source. These are analogous to phone numbers. 
For such access tests, the communication would need to be established and authorization obtained before the right 
could be exercised. 

For one-time usage rights, a variant on this schenrte is to have a digital ticket. A ticket Is presented to a digital ticket 
agent, whose type is specified on the ticket. In the simplest case, a ceftified generic ticket agent, available on all 
repositories, is available to "punch" the ticket. In other cases, the ticket may contain addressing information for locating 
a -special" ticket agent. Once a ticket has been punched, it cannot be used again lor the same kind of transaclion 
(unless it is unpunched or refreshed in the nranner described below.) Punching includes marking the ticket with a 
timestamp ol the date and time It vras used. Tickets are digital works and can be copied or transferred between repos- 
itories according to their usage rights. 

In the currently preferred embodiment, a "punched" tteket becomes "unpunched" or "refreshed" when il is copied 
or extracted. The Copy and Extract operations save the date and lime as a property of the digital ticket. Whan a ticket 
agent is given a ticket, it can simply check whether the digital copy was made after the last time that it was punched, 
01 course, the digital ticket must have the copy or extract usage rights attached thereto. 

The capability to unpunch a tteket is inportant in the loltowing cases: 

• A digital work is circulated at low cost with a limitation that it can be used only once. 

• A digital work is circulated with a ticket that can be used once to give discounts on purchases of other works. 

• A digital work is circulated with a ticket (included in the purchase prfce and possibly embedded in the work) that 
can be used lor a future upgrade. 

In each of these cases, if a paid copy is made of the digital work (including the ticket) the new owner would expect 
to get a fresh (unpunched) ticket, whether the copy seller has used the work or not. In contrast, toaning a work or simply 
transferring it to another repository should not revitalize the ticket. 

Usage Fees and Incentives Specification 

The billing for use of a digital work is fundamental to a commercial distribution syste-ts. Gra.mmar Element 1517 
•Fee-Spec: s {Schedoted-Dlscount} Regular-Fee-Spec I Scheduled-Fee-Spec I Marlciip-Spec" provides a langa 
of options for billing for f^fe use of di.jiial wori-$-. 

/ ^ey feature of th • approact-. fs the o-velopr- -.i of Ic overhead t; tor trar:ft.=.. 'one pc .>..i<aSv -i 3"1 
amoufiis. Thus, ii becoiTK-..i; feasible to collet-; tees <:■■ ily a U-... cents eaci, Mciusanoc : »rani,i.(;tior. • 

The grammar differentiates between uses where the charge is per use Ircm those wtief? it is metered liy the tima 
unit. Transactkjns can support fees that the user pays for using a digital woik as well as incentives paxS by the nynt 
grantor to users to induce them to use or distribute the digital work. 

The optional scheduled discount refers to the rest of the fee specincation-discounling it by a percentage over 
lime. If it Is not specified, then there is no scheduled discount. Regular fee specifications are constant over time. 
Scheduled fee specifications give a schedute of dates over whreh the tee specifications change. IVIarkup specifications 
are used m d-blocks for adding a percentage to the fees already being charged. 

Grammar Element 1518 "Scheduled-Discount:= (Scheduled-Discount: (Time-Spec Pereentagen* ASched- 
uled-Discount is a essentially a scheduled modifier of any other lee specification lor this version of the right of the 
digital work. (It does not reler to children or parent digital works or to other versions of rights.). It Is a list ol pairs ol 
times and percentages. The most recent time in the list that has not yet passed at the time of the transaction is the 
one in effect. The percentage gives the discount percentage. For example, Ihe number 10 refers to a 10% discount. 

Grammar Element 1519 "Regular-Fee-Spec : = ({Fee: I Incentive: } [Per-Use-Spec I Metered-Rate-Spec I 
Best-Price-Spec I Call-For-Prlce-Spec ] {Mln: IWoney-Unit Per: Tlme-Spec){Max: Money-Unit Per: Time-Spec) 
To: Account-ID)" provides for several kinds of fee specifications. 

Fees are paid by the copy-owner/user to the revenue-owner if Fee: is specified. Incentives are paid by the revenue- 
owner to the user if Incentive: is specified. If the Mln: specification is given, then there is a minimum fee to bo charged 
per time-spec unit for Its use. If the Max: specification is given, then there is a maximum fee to be charged per time- 
spec for its use. When Foe: is specified. Account-ID Identifies the account to which the fee is to be paid. When In- 
centiwe:-ls specified. Aeeount-IO identifies Ihe account from which the fee is to be paid. 

Grammar element 1 520 ■Per-Use-Spee:s Per-Use: Money-unif defines a simple fee to be paid every time the 
right is exercised, regardless of how much time the transaction lakes. 
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Grammar element 1 521 'Metered-Rate-Spee : s Metered: Money-Unit Per: Time-Spec' defines a metered-iaie 
fee paid according to how long the right is exercised. Thus, the time it taltes to complete the Iransaclion determines 
the fee. 

Grammar element 1522 " Best-Price-Spec : s Best-Price: Money-unft Max: Money-unit" is used lo specify a 

s best -price that is determined when the account is settled. This specification is lo accommodate special deals, rebates, 
and pricing that depends on information that is not available to the repository. All fee specifications can be combined 
with tickets or authorizations that could indicate that the consumer is a wholesaler or thai he is a preferred customer, 
or that the seller be authorized in some way. The annount of money in the Max: field is the maximum amount thai the 
use will cost. This is the amount that is tentatively debited from the credit sender. However, when the transaction is 

10 ultimately reconciled, any excess amount will be returned to the consumer in a separate transaction. 

Grammar element 1523 'Call-For-Price-Spec : = Cali-For-Price " is similar to a °Best-Prlce-Spec' in that it is 
intended to accommodate cases where prices are dynamic. A Call-For-Price Spec requires a communication with a 
dealer to determine the price. This option cannot be exercised if the repository cannot communicate with a dealer at 
the time that the right is exercised. It is based on a secure transaction whereby the dealer names a price lo exercise 

15 the right and passes along a deal certificate which is referenced or included in the billing process. 

Grammar element 1524 'Seheduled-Fee-Spec: s (Schedule: (Time-Spec Regular-Fee-Spec)*)" is used to pro- 
vide a schedule ol dates over which the tee specifications change. The lee specification with the most recent date not 
in the luture is the one that is in eflect. This Is similar lo but more general than the scheduled discount. It is more 
general, because it provides a means to vary the fee agreement for each time period. 

20 Grammar element 1525 'Markup-Spec: s Markup: percentage To: Account-ID* Is provided lor adding a per- 

centage to Ihe fees already being charged. For example, a 5% markup means that a tee of 5% of cumulative fee so 
far will be allocated to the distributor. A markup speciricatk>n can be applied to all of the other kinds of fee specifcations. 
It is typically used in a shell provided by a distributor. It refers to fees associated with d-blocks that are parts of the 
current d-btock. This might be a convenient specification for use in taxes, or in distributor overhead. 

ss 

REPOSITORY TRAI^SACTIONS 

When a user requests access to a digital work, the reposiloiy will Initiate various transactkms. The combination 
of transactions invoked will depend on the specifications assi{pied for a usage right. There are three basic types of 

so transactions. Session Initiatkxi Transaclions, Financial Transactions and Usage Transactions. Generally, session ini- 
tiation transactions are initiated first to establish a valid session. When a valid session is established, transactions 
corresponding to the various usage rights are invoked. Finally, request specific transactions are performed. 

Transaclions occur between two repositories (one acting as a server), between a repository and a document play- 
back platform (e.g. lor executing or viewing), between a repository and a credit sewer or between a repository and an 

35 authorization senrer. When transactions occur between more than one repository, it is assumed that there is a reliable 
communication channel between the repositories. For example, this couM be a TCP/IP channel or any other commer- 
cially available channel that has built-in capabilities for detect'ng and correcting transmissnn errors. However, it is not 
assumed that the communication channel is secure. Proviskms for security and privacy are part of ihe requirements 
for specifying and implementing repositories and thus fomn the need for various transacttons. 

40 

Message Transmission 

Transactions require that there be some communication between repositories. Communcatun between reposi- 
tories occurs in units termed as messages. Because the communication line is assumed to be unsecure, an commu- 
nications with repositories that are above the lowest security class are encrypted utilizing a public key encryption 
technique. Public key encryption is a well known technique in the encryption arts. The term key refers to a numeric 
code that is used with encryption and decryption algorithms. Keys come in pairs, where 'writing Iteys' are used to 
encrypt data and 'checking keys' are used to decrypt data. Both writing and checking keys may be public or private. 
Publk: keys are those that are distributed to others. Private keys are maintained in confidence. 
so Key management and security is instrumental in the success of a public key encryption system. In ihe currently 
preferred embodiment, one or more master repositories maintain the keys and create the kfentificatton certificates 
used by the repositories. 

When a sending repository transmits a message to a receiving repository, tho sending repository encrypts all of 
its data using the public writing key o( the receiving repository. The sending repository includes its name, Ihe name of 
ss the receiving repository, a session identifier such as a nonce (described below), arKl a message counter in each mes- 
sage. 

In this way, the communication can only be read (to a high probability) tty the receiving reposiloiy, which holds the 
private checking key for decryptkm. The auxiliary data is used to guard against various replay attacks to security If 
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messages ever arrive with the wrong counter or an old nonce, the repositories can assume thai someone is inlerlering 
whh communicallon and the transaction terminated. 

The respective public keys for the repositories to be used (or encryption are obtained in the registration transaction 
described below. 

5 

Session Initiation Transactions 

A usage transaction is carried out in a session between repositories. For usage transactions involvng more than 
one repository, or for financial transactions between a repositoiy and a credit senrer, a registration transaction is per- 

10 formed. A second transaction termed a login transaction, may also be needed to initiate the session. The goal of the 
registration transaction is to establish a secure channel between two repositories who l<now each others identities. As 
it is assumed that the communication channel between the repositories is reliable but not secure, there is a risk that 
a non-repository may mimic the protocol in order to gain illegitimate access to a repository. 

The registration transaction between two repositories Is described with respect to Figures 16 and 17. The steps 

75 described are from the perspective of a *repositoty-1 * registering its identity with a 'repository-2'. The registration must 
be symmetrical so the same set of steps will be repeated for .repository-2 registering its identity with repository-1 . 
Referring to Figure 16, reposiiory-l first generates an encrypted registration identifier, step 1601 and then generates 
a registration message, step 1602. A registration message Is comprised ol an identilier ol a master reposiiory, the 
Identification certificate (or the repository-1 and an encrypted random registration identifier. The Identification certificate 

20 is encrypted by the master repository in its private key and attests to the fact that the repository Oiere repository-1 ) is 
a bona fide repository. The identincatlon certificate alsocontains a public key (or the repository, the repositoiy security 
level and a timestamp (indicating a time after which the certificate is no-longer valid.) The registration identifier is a 
number generated by the repositoiy for this registration. The registration Identifier is unique to the session and is 
encrypted in repository-1's private key. The registration identifier is used to improve security of authentication by de- 

2S tccting certain kinds of communications based attacks Ropository-1 then transmits tho registration message to ropos- 
itoiy-2, step 1603. 

Upon receiving the registration message, repositoiy-2 determines if it has the needed public key for the master 
repository, step 1604. II repositoiy-2 does not have the needed public key to decrypt the identification certificate, the 
registration transaction terminates in an error, step16l8. 

30 Assuming that repositoiy-2 has the proper publk: key the identification certificate is decrypted, step 1 605. Repos- 

itofy-2 saves the encrypted registration Identifier, step 1606. and extracts the repository identifier, step 1607. The 
extracted repository identifier is checked against a "hotlisf of compromised document repositories, step 1608. In the 
currently preferred embodiment, each repository vrill contain "hotlists" of compromised repositories. It the repository 
is on the 'hotiist', the registration transaction terminates in an error per step 1 618. Repositories can be removed from 

3S the hotlist when their certificates expire, so that the list does not need to grow without bound. Also, by keeping a short 
list of hotlist certificates that it has previously received, a repository can avoid the work of actually going through the 
list, These lists would be encrypted by a master repository. A minor variation on the approach to improve efficiency 
would have the repositories first exchange lists of names of hotlist certificates, ultiniately exchanging only those lists 
that they had not previously received. The "hotlists* are maintained and distributed by Master repositories. 

^0 Note that rather than terminating in error, the transaction could request that another registration message be sent 

based on an identification certificate created by another master repository. This may be repeated until a satisfactory 
identification certificate is found, or it is determined thai trusi cannot be established. 

Assuming that the repository is not on the hotlist. the repository identification needs to be verified. In other words, 
repository-2 needs to validate that the repository on the other end is really repositoiy-1 . This is termed performance 
testing and is performed in order to avoid invalid access to the repository via a counterfeit repository replaying a re- 
cording of a prior session initiation between repositoiy-1 and repositoiy-2. Performance testing is initiated by repository- 
2 generating a performance message, step 1609. The petformance message consists of a nonce, the names of the 
respective repositories, the time and the registration idenliliei received from repository-1. A nonce is a generated 
message based on some random and variable Information (e.g. the time or the temperature.) The nonce is used to 

5" check whether repository-1 can actually exhibit conrect encrypting ol a message using the private keys it claims to 
have, on a message that it has never seen before. The pertormance message is encrypted using the public key specified 
in the registration message of repository-1 . The performance message is transmitted to repositoiy-1 , step 1610, where 
it is decrypted by reposilory-1 using its private koy, step 1611. Rcposilory-1 then chocks to make sure that the names 
of the two repositories are correct, step 1612. that the time is accurate, step 1613 and that the registration identifier 
corresponds to the one it sent, step 1614. If any of these tests fails, the transaction is temfiinated per step 1616. 
Assuming that the tests are passed, repositoiy-1 transmits the nonce to repository-2 in the clear, step 1615. Repository- 
2 then compares the received nonce to the original nonce, step 1617. If they are not identical, the registratton transaction 
terminates in an error per step 1618. If they are the same, the cegistratton transaction has successfully completed. 
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At this point, assuming thai Ihe Jransaclion has not terminated, the repositories exchange messages containing 
session keys to be used in all communications during Ihe session and synchronize their clocks. Figure 17 illustrates 
the session information exchange and clock synchronization steps (again Irom the perspective of reposilory-1 .) Re- 
ferring to Figure 17, repository-1 creates a session key pair, step 1701. A first key is kept private and is used by 
repository-1 to encrypt messages. The second key is a public key used by repository-2 to deciypi messages. The 
second key is encrypted using the public key of repository-2, step 1702 and is sent to repository-2. step 1703. Upon 
receipt, reposilory-2 decrypts the second key step 1704. The second key is used to decrypt messages in subsequent 
communications. When each repository has completed this step, they are both convinced that the other repository is 
bona fide and that they are communicating v/ith the original. Each repositoiy has given the other a key to be used in 
decrypting further communications during the session. Since that key is itself transmitted in the public key of the re- 
ceiving repository only it will be able to decrypt the key which is used to decrypt subsequent messages. 

After the session information is exchanged, the repositories must synchronize their clocks. Clock synchronization 
is used by the repositories to establish an agreed upon time base for the financial records of their mutual transactions. 
Referring hiack to Figure 1 7. repository-2 initiates clock synchronization by generating a time stamp exchange message, 
step 1705, and transmits it to reposilory-1, step 1706. Upon receipt, reposilory-1 generates its own time stamp mes- 
sage, step 1707 and transmits it back to reposttory-2. step 1703. Repositoiy-2 notes the current time, step 1709 and 
stores the time received! rom repository-1 , step 1 71 0. The current time iscomparedto the time received from repository- 
1 , step 1711. The difference is then checked to see il it exceeds a predetermined tolerance (e.g. one minute), step 
1712, If it does, repository-2 terminates the transaction as this may indicate tampering with the repository, step 1713. 
If not reposiioty-2 computes an adjusted lime delta, step 1714. The adjusted lime delta is Ihe difference between the 
clock time of repository-2 and the average of the times Irom repository-1 and repository-2. 

To achieve greater accuracy, reposltoiy-2 can request the lime again up to a fixed number of limes (e.g. five times), 
repeat the clock synchronization steps, and average the results. 

A second session initiation transaction is a Login transaction. The Login transaction is used to check the authenticity 
of a user requesting a transaction. A Login transaction is particularly prudent for the authorization of financial transac- 
tions that will be charged to a credit sen/er. The Login transactk)n involves an interaction between the user at a user 
interface and the credit server associated with a repository. The inlomiation exchanged here is a login string supplied 
by Ihe repository/credit server to Identify itself to the user, and a Personal Identification Number (PIN) provided by the 
user to klantiiy himself to Ihe credit sen/er. In Ihe event that the user is accessing a credit server on a repository different 
from the one on which the user interface reskles. exchange of the Information would be encrypted using the public and 
private keys of the respective repositories. 

Billing Transactions 

Billing Transactions are concerned wHh nionelary trsbisactlons yvith a credit server. Billing Transactions are carried 
out when ad other conditions are satisfied and a usage fee Is required for granting the request For the most part, billing 
transactions are well understood in the state of ttiearL These transactions are between a repository and a credit server, 
or between a credit server and a biiling clearinghouse. Briefly, the required transactions include the following: 

• Registration and LOGIN transactions by which Ihe repository and user establish their bona fides to a credit server. 
These transactions would be entirely internal in cases where the repository and credit senrer are implemented as 
a single system. 

• Registration and LOG IN transactions, by which acredit sen/er establishes its bona fides toa billing clearinghouse. 

• An Assign-lee transaction to assign a charge. The information in this transaclKin would include a transaction fclen- 

tifier, the idenlities ot the repositories In the transaction, and a list of charges trom Ihe pans of Ihe digital work. If 
there has been any unusual event in the transaction such as an inierruption of communications, that information 
is included as well. 

• A Begin-chatges transaction lo assign a charge. This iransaclion is much the same as an assign-fee transaclton 
except that it is used lor metered use. It includes Ihe same uiformation as the assign-fee transaction as well as 
the usage fee information. The credit-senrer is then responsible for runnirig a clock. 

• An End-charges transaction to end a charge for metered use. (In a variation on this approach, the repositories 
would exchange periodic charge information lor each block of time.) 

A report-charges transaction between a personal credit sen/er and a bijling clearinghouse. This transaction is 
invoked at least once per billing period. It is used to pass along ffiformation about charges. On debit and credit 
cards, this transaction would also be used to update balance mformation and credit limits as needed. 

All billing iransactions are given a transaction 10 and are reported to the credit severs by both Ihe server and Ihe 
client. This reduces possible loss of billing information if one of the parties to a transaction loses a banking card and 
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provides a check against tampering with the system. 
Usage Transactions 

s After liie session initiation transactions have been completed, the usage request may then be processed. To sim- 
plify the description ol the steps carried out in processing a usage request, the term requester is used to refer to a 
repository in the requester mode which is initiating a request, and the lemn server is used to refer to a repository in the 
server mode and which contains the desired digital work. In many cases such as requests to prim or view a work, the 
requester and server may be the same device and the transactions described in the folbwing would be entirely internal. 

10 In such instances, certain transaction steps, such as the registration transaction, need not be performed. 

There are some common steps that are part of the semantics of all of the usage rights transactions. These steps 
are referred to as the common transaction steps. There are two sets -the 'opening' steps and the 'closing' steps. For 
simplicity, these are listed here rather than repeating them in the <lescrq)tions of all of the usage rights transactions. 
Transactions can refer to a part of a digital work, a complete digital work, or a Digital work containing other digital 

IS works. Although not described in detail herein, a transaction may even refer to a folder comprised of a plurality of digital 
works. The term "work" is used to refer to what ever portion or set of digital works is being accessed. 

I^any ol the steps here involve determining it certain conditions are satisfied. Recall thai each usage right may 
have one or more conditions which must be satisfied before the right can be exercised. Digital works have parts and 
pans have parts. Different parts can have different rights and fees. Thus, it Is necessary to verity thai the requirements 

£0 are met for ALL of the parts that are involved In a transaction For brevity, when reference is made to checking whether 
the rights exist and conditions for exercising are satisfied, it is meant that all such checking takes place for each of the 
relevant parts of the work. 

Figure 1 8 Illustrates the initial common opening and closing steps for a transactkm. At this point it Is assumed that 
registration has occurred and that a 'trusted' session is in place. General tests are tests on usage rights associated 

2£ with the foldorcontalning the work or some containing folder higher in the file system hierarchy. These tests correspond 
to requirements Imposed on the work as a consequence of its being on the particular reposito^, as opposed to being 
attached lo the work itsell. Referring to Figure 18, prior to initiating a usage transaction, the requester performs any 
general tests that are required before the right associated with the transactkjn can be exercised, step, 1801. For ex- 
ample. Install, uninstall and delete rights may be implemented to require that a requester have an authorization certif- 

30 icate before the right can be exercised. Another exampte is the requirement that a digital ticket be present and punched 
before a digital work may be copied to a requester. If any of the general tests fail, the transaclbn is not in itiated, step. 
1802. Assuming that such required tests are passed, upon receiving the usage request, the server generates a trans- 
action identifier that is used in records or reports of the transaction, step 1803. The server then checks whether the 
digital work has been granted the right corresponding to the requested transaction, step 1804. If the digital work has 

3S not been granted the right corresponding to the request, the transactbn tennihates, step 1 SOS. If the digital work has 
been granted the requested right, the server then determines if the various conditions for exercising the right are 
satisfied. Tme based conditkxis are examined, step 1806. These conditions are checked by examining the time spec- 
ification for Ihe the version of the right. If any of the conditions are not satisfied, the transaction terminates per step 1 805. 
Assuming that the time based conditions are satisfied, the server checks security and access conditions, step 

40 1 807. Such security and access conditions are satisfied if: 1 ) the requester is at the specified security class , or a higher 
security class. 2) the server satisfies any specified authorization test and 3) the requester satisfies any specified au- 
thorizatbn tests and has any required digital tickets. If any of the conditions are not satisfied, the transaction tenrunates 
per step 1805. 

Assuming that the security and access c6nditK>ns are all satisfied, the senrer checks the copy count condition, 
4S Step 1 808. If the copy count equals zero, then the transaction cannot be completed and the transaction terminates per 
step 1805. 

Assuming that the copy count does not equal zero, the server checks i the copies in use for the requested ri^t 
Is greater than or equal to any copy count for the requested right (or refevant parts), step 1809. If the copies in use is 
greater than or equal to the copy count, this indicates that usage rights tor the version of the transaction have been 

so exhausted. Accordingly, the server terminates the transaction, step 1805. If the copy count is less than the copies in 
use lor the transaction the transaction can continue, and the copies in use would be incremented by the number of 
digital worths requested in the transactksn, step 1810. 

The server then checks if the digital work has a 'Loan' access right, slop 1811 . The 'Loan' access right is a special 
case since remaining rights may be present even though all copies are loaned out. If the digital work has the 'Loan' 

ss access right, a check is made to see it all copies have been loaned out, step 1812. The number of copies that could 
be loaned is the sum of the Copy-Counts for atl of the versnns of the loan right of the digital work. For a composite 
work, the relevant figure is the minimal such sum of each of the components of the composite woric. If afl copies have 
been loaned oul. Ihe remaining rights are determined, step 1 81 3. The remalning-rightsis determined from the remaining 
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rights specifications Irom the versions ol the Loan right If there Is only one version ol the Loan right, then the deter- 
mination is simple. The remaining rights are the ones specified in that version of the Loan right, or none if Remainirg- 
Righis: is not specified. If there are multiple versions of the Loan right and all copies of all of the versions are loaned 
out. then the remaining rights is taken as the minimum set (uilersection) of remaining rights across all of the versions 
s of the loan right. The server then detennuies i( the requested right is in Ihe set of remaining rights, step 1814. If the 
requested right is not In the set of remaining rights, the server terminates the transaction, step 1805. 

If Loan is not a usage right for the digital work or if all copies have not been loaned out or the requested right is in 
the set of remaining rights, fee conditions for the right are then checked, step 1815. This will initiate various linancial 
transactions between the repository and associated credit servec Further, any metering of usage ol a digital work will 
10 commence. If any financial transaction fails, the transactior) terminates per step 1805. 

It should be noted that the order in which the conditions are checked need not follow the order of steps 1 806-181 5. 

At this point, right specific steps are now perfonned and are represented here as step 1816. The right specific 
steps are described in greater detail below. 

The common closing transaction steps are now performed. Each of the closing transaction steps are performsd 
'£ by the sen/er after a successful complelkMi of a transaction. Referring back to Figure 18. the copies In use value lor 
the requested right is decremented by Ihe number ot copies involved in the transaction, step 1817. Next, if the right 
had a metered usage lee specification, the sen/er subtracts the elapsed time from the Remaining-Use-Time associated 
with the right lor every part involved in the transaction, step 1818. Finally, H there are lee speciflcations associated 
with the right, Ihe senrer initiates End-Charge financial transaction to confirm billing, step 1819. 

20 

Transmission Protocol 

An important area to consider is the transmission of the digital work from the sewer to (he requester. The trans- 
mission protocol described herein refers to events occurring after a valid session has been created. The transmisston 
protocol must handle the case ot disruption in Ihe communications between the repositories. It is assumed that inter- 
ference such as injecting noise on the communication channel can be detected by the integrity checks (e.g., parity, 
checksum, etc.) that are built into the transport protocol and are not discussed in detail herein. 

The underlying goal in the transmission protocol is to preclude certain failure modes, such as malicious or accidental 
interference on the communications channel. Suppose, for example, that a user pulls a card with the credit sen/er at 
30 a specific time near the end of a Iransactbn. There should not be a vulnerable time at which 'pulling the card' causes 
the repositories to fail to correctly account lor the number of copies of Ihe work that have been created. Restated, there 
should be no time at which a party can break a connactkin as a means to avoid payment after using a digital work. 

If a transaction is interrupted (and fails), both repositories restore the digital worics and accounts to their state prior 
to the failure, modulo records of the failure itself 
35 Figure 19 is a state diagram showing steps in the process ol transmitting information during a transaction. Each 
box represents a state of a repository In either the sen/er mode (above the central dotted line 1 901 ) or in the requester 
mode (below the dotted line 1 901 ). Solid arrovrs stand for transitions between states. Dashed arrows stand for message 
communications between the repositories. A dashed message arrow pointing to a solid transition arrow is interpreted 
as meaning that the transition takes place when the message is received. Unlabeled transition arrows take place 
40 unconditionally Other labels on state transitkm arrows describe conditions that trigger the transilbn. 

Referring now to Figure 19, the sen/er is inKially in a state 1902 where a new transaction is initiated via start 
message 1903. This message includes transaction Information including a transaction identifier and a count ot the 
blocks ol data to be transferred. The requester, initially in a wait state 1904 then enters a data wait state 1905. 

The server enters a data transmit state 1906 and transmits a block ot data 1 907 and then enters a wrait tor ac- 
« knowledgement state 1 908. As the data is received the requester enters a data receive slate 1 909 and when the data 
blocks are completely received it enters an acknowledgement state 1 910 and transmits an Acknowledgement message 
191 1 to the sen/er. 

If there are more blocks to send, the sen/er waits unlil receiving an Acknowledgement message from the requester 
When an Acknowledgement message is received it sends the next block lo the requester and again waits for acknowl- 
so edgement. The requester also repeats the same cycle of states. 

II the server delects a communications lailure before sending the last btock, it enters a cancellation state I9i2 
wherein the transaction is cancelled. Similarly, il the requester detects a communications failure before receiving the 
last block it enters a cancellation state 1913. 

1 1 there are no more blocks to send, the sen/er commits to the transaction and waits for the linal Acknowledgement 
in state 1 91 4. II there is a communications lailure betore the sen/er receives the final Acknowledgement message, it 
still commits to the transaction but includes a report about the event to lis credit sen/er in state 1915. This report serves 
two purposes. It will help legitimize any claims by a user of havnig been billed lor receiving digital works that were not 
completely received. Also it helps to kJentily repositories and communicalmns.lines that have suspicious pallerns of 
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use and interruption. The sen/er then enters its completion state 1916. 

On the requester side, when there are no more blocks to receive, the requester commits to the transaction in stale 
1917. 1( the requester detects a communications failure at this state, it repons the failure to its credit server in state 
191 8. but still commits to the transaclion. When it has committed, it sends an acknowledgement message to the server. 
The server then enters its cotrplerion state 1919. 

The key properly is that both the server and the requester cancel a transaction if it is interrupted before all of the 
data blocks are delivered, and commits to it if all of the data blocks have been delivered. 

There is a possibilily that the sen/er will have sent all of the data blocks (and committed) but the requester will not 
have received all of them and will cancel the transaction. In this case, botlt repositories will presumably delect a com- 
munications failure and report it to their credit server. This case will probably be rare since it depends on very precise 
liming of the communications failure. The only consequence will be that the user at the requester repository may want 
to request a refund from the credit services - and the case for that refund will be documented by reports by both 
repositories. 

To prevent loss of data, the senrer shoukJ not delete any transferred digital work until receiving the final acknowl- 
edgement Irom the requester. But it also should not use the file. A well known way to deal with this situation is called 
■iwo-phase commit" or 2PC. 

Two-phase commit works as loltows. The first phase works the same as the method described above. The server 
sends all of the data to the requester. Both repositories mark the transaction (and appropriate lilas) as uncommined. 
The server sends a ready-lo-commit message to the requester. The requester sends back an acknowledgement. The 
server then commits and sends the requester a commit message. When the requester receives the commit message, 
it commits the file. 

II there is a communication failure or other crash, the requester must check back with the server to determine the 
status of the transactfon. The server has the last word on this. The requester may have received all of the data, but if 
it did not gel the final message, it has not committed. The senrer can go ahead and delete files (except for transaction 
records) once it commits, since the files are known to have been fuUy transmitted before starting the 2PC cycle. 

There are variations known in the art which can be used to achieve the same effect. For example, the server could 
use an addittonal level of encryption when transmitting a work to a client. Only after the client sends a message ac- 
knowledging receipt does it send the key. The client then agrees to pay for the;digital work. The poinl of this variation 
Is thai ii provides a clear audit trail that the client received the work. For trusted systems, however, this variation adds 
a level of enciyption for no real gain in accountability 

The transaction for specific usage rights are now discussed. 

The Copy Transaction 

A Copy transaction is a request to make one or more independent copies of the work with the same or lesser 
usage rights. Copy differs from the extraction right discussed later in that it refers to entire digital works or entire folders 
containing digital works. A copy operation cannot be used to remove a porlnn of a digital wori<. 

• The requester sends the sewer a message to initiate the Copy Transaclion. This message indicates the work to 
be copied, the verston of the copy right to be used for the transaction, the desUnatkxi address information (location 
in a folder) for placing the work, the file data for the work (including its size), and the number of copies requested. 

• The repositories perform the common opening transaclnn steps. 

• The server transmits the requested contents and data to the client according to the transmission protocol. 11 a 
Next-Set-OI-Rights has been provided in the version of the right, those rights are transmitted as the rights for the 
work. Otherwise, the rights of the original are transmitted. In any event, the Copy-Count field for the copy of the 
digital work being sent right is set to the number-of-copies requested. 

• The requester records the work contents, data, and usage rights and stores the work. It records the date and time 
that the copy was made in the properties of the digital work. 

• The repositories perform the common closing transaction steps. 

The Transfer Transaction 

A Transfer transaclion is a request to move copies of the work with the same or lessor usage rights to another 
repository. In contrast with a copy transaclion. this results in removmg the worii copies from the sen/er. 

• The requester sends the sen/er a message to initiate the Transfer Transaction. This message indicates the work 
to be transferred, the version of the transfer right to be used in the transaction, the destination address informatton 
for placing the work, the file data for the work, and the number of copies involved. 
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• The repositories perform the common opening transaction steps. 

• The server transmits the requested contents and data to the requester according to the transmission protocol. If 
a Next-Set-OI-Rights has been provided, those rights are transmitted as the rights (or the work. Olhenwise. the 
rights of the original are transmitted. 

s In either case, the Copy-Count field for the transmitted rights are set to the number-o(-copies requested. 

• The requester records the work contents, data, and usage rights and stores the work. 

• The server decrements its copy count by the number <rf copies involved in the transaction. 

• The repositories perform the common closing liansaclion steps. 

• If the number of copies remaining in the sereer is now zero, it erases the digital work Irom its memory. 

10 

The Loan Transaction 

A loan transaction is a mechanism for loaning copies of a digital work. The maximum duration of the toam is de- 
termined by an internal parameter of the digital work. Works are automatically returned after a predetermined time 
»5 period. 

The requester sends the sen/er a message to Initiate the Transfer Transaction. This message indicates the work 
to be loaned, the version of the loan right to be used in the transaction, the destination address information (or 
placing the work, the number of copies involved, the (ile data (or the vrork. and the period o( the loan. 
The server checks the validity of the requested loan period, and ends with an error II the period is not valid. Loans 
for a loaned copy cannot extend beyond the period of the original loan to the sen/er. 
The repositories perform the common opening transaction steps. 

The server transmits the requested contents and data to the requester. If a Next-Set-Of-Rights has been provided, 
those rights are transmitted as the rights (or the work. Othcnwise. the rights of the original are Iransmiited. as 
modified to reflect tho loan period. 

The requester records Iho digital work contents, data, usage rights, and loan period and stores the work. 
The server updates the usage rights informatton in the digital work to reflect the number of copies loaned out. 
The repositories perfom) the common closing transactkm steps. 

The sen/er updates the usage rights data for the digital work. This may preclude use of the work until It is retumed 
from the loan. The user on the requester platform can how use the transferred copies of the digital work. A user 
accessing the original repository cannot use the digital work . unless there are copies remaining. What happens 
next depends on the order of events in time. 

Casel. If the lime of the loan perkxJ is not yet exhausted and the requester sends the repository a Return message. 
The return message includes the requester identificatkxi, and (he transaction ID. 

The server decrements the copies-in-use field by the number of copies that were retumed. (If the nun*er of digital 
works retumed is greater than the number actually borrowed, this is treated as an enror.) This step may now make 
the work available at the sen/er for other users. 

The requester deactivates Its copies and removes the contents from its memory. 

Case 2 . If the time of the loan perkxl is exhausted and the requester has not yet sent a Return message. 

The server decrements the coples-in-use field by the number digital works that were borrowed. 
The requester automatically deactivates its copies of the digital work. It terminates all current uses and erases the 
digital work copies from memory. One question is why a requester would ever return a work earlier than the period 
of the ban, since it wouW be returned automatically anyway. One reason for early return is that there may be a 
metered fee whch determines the cost of Ihe loan. Returning early may reduce that fee. 

so The Play Transaction 

A play transaction is a request to use the contents of a work. Typically, to "play" a work is to send the digital work 
through some kind of transducer, such as a speaker or a display device. Tho request impfies the intention that the 
conlonts will not be communicated digitally to any other system. For example, they will not be sent to a printer, recorded 
on any digital medium, retained after the transaction or sent to another repository. 

This term 'play' is natural for examples like playing music, playing a movie, or playing a video game. The general 
form of play means that a 'player* is used to use the digitat work. However, the tenn play covers all media and kinds 
of recordings. Thus one would "play" a digital worit, mean'ng, to render it for reading, or play a computer program. 
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meaning to execute it. For a digital ticket the player would be a digital ticket agent. 

• The requester sends the server a message to initiate the pla/ transaction. This message Indicates the work to be 
played, the version of the play right tobe used in (he transaction, the identity of the player being used, and the file 
data for the work. 

• The server checks the validity of the player identification and the compatibility of the player Identification with the 
player speciFication in the right. It ends with an error if these are not satisfactory. 

• The repositories perform the common opening transaction steps. 

• The server and requester read and write the blocks of data as requested by the player according to the transmission 
protocol. The requester plays the work contents, using the player. 

• When the player is finished, the player and the requester remove the contents from their memory. 

• The repositories perform the common closing transaction steps. 

The Print Transaction 

A Print transaction is a request to obtain the contents of a work lor the purpose of rendering them on a "printer* 
We use the term 'primer" to Include the common case of writing with ink on paper. However, ihe key aspect of "printing" 
in our use of ttie lerm is that II makes a copy of the digital work in a place outside of the protection of usage rights. As 
with all rights, this may require paatcular aulhorizaiion certificates. 

Once a digital work is printed, the publisher and user are bound by whatever copyright laws are in eflect. However, 
printing moves the contents outskje the control of repositories. For example, absent any other enforcement mecha- 
nisms, once a digital work is printed on paper, it can be copied on ordinary photocopying machines without intervention 
by a repository to collect usage lees. II the printer to a digital disk is permitted, then that digital copy is outside of the 
control ol usage rights. Both the creator and the user know this, although the creator does not necessarily give tacit 
consent to such copying, which may violate copyright laws. 

• The requester sends the sewer a message to initiate a Print transaction. This message indtoates the work to be 
played, the identity of the printer being used, the file data for the work, and the numt>er of copies in the request. 

• The senrer checks Ihe validity of the printer identificalkm and the compatibility of the printer Identification with the 
printer specification in the right. It ends with an error if these are not satisfactory. 

• The repositories perform the common opening transaction steps. 

• The sewer transmits blocks of data according to the transmission protocol. 

• The requester prints the work contents, using the printer. 

• When the printer is finished, the pr'mter and the requester remove the contents from their memory. 

• The repositories perform the common closing transaction steps. 

The Backup Transaction 

A Backup transaction is a request to make a backup copy ol a digital wori<, as a protection against media failure. 
In the context of repositories, secure backup copies differ from other copies in three ways: (1) they are made under 
the control of a Backup transaction rather than a Copy transaction, (2) they do not count as regular copies, and (3) 
they are not usable as regular copies. Generally, backup copies are encrypted. 

Although backup copies may be transferred or copied, depending on their assigned rights, Ihe only way to make 
them uselul for playing, printing or embedding is to restore them. 

The output of a Backup operation is both an encrypted data file that contains the contents and description of a 
work, and a restoration file with an encryption key for restoring the encrypted contents. In many cases, the encrypted 
data file would have rights for "printing' it to a disk outside of the protection system, relying just on Its encryption for 
security. Such files could be stored anywhere that was physically sale and convenient. The restoration lile would be 
held in the repository'. This file is necessary for the restoratton of a backup copy It may have rights for transfer between 
repositories. 

• The requester sends the server a message to initiate a Ijackup transactk>n. This message indicates the work to 
be backed up, the version ol tho backup right to be used in the transaction, the destination address information 
for placing the backup copy, the file data for the vwrk. 

• The repositories periorm the common opening transacUon steps 

• The sen/er transmits the requested contents and data to the requester. If a fslext-SetOf-Rights has been provided, 
those rights are transmitted as the rights for the work. Othenvise, a set of default rights for backup files of the 
original are transmitted by the server. 
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• The requester records the work contents, data, and usage rights. It then creates a one-time key and encrypts the 
contents file. It saves (he key infonnalion in a restoration file. 

• The repositories perform the common closing transaction steps. 

5 In some cases, it is convenient to be able to archive the large, encrypted contents file to secure offline storage, 

such as a magneto-optical storage system or magnetic tape. This creation of a non-reposilory archive file is as secure 
as the encryption process. Such non-repository archive storage Is considered a fomool 'printing* and is controlled by 
a print right with a specified 'archive-printer.' An archive-printer device is programmed to save the encrypted contents 
file (but not the description file) offline in such a way that it can be retrieved. 

TO 

The Restore Transaction 

A Restore transaction is a request to convert an encrypted backup copy of a digital work into a usable copy A 
restore operation is intended to be used to compensate for catastrophic media failure. Like all usage rights, restoration 
IS rights can include fees and access tests including authorization checks. 

• The requester sends the server a message to initiate a Restore transaction. This message indicates the work to 
be restored, the version of the restore right lor the transaction, the destination address information for placing the 
work, and the file data for the work. 

20 • The server verifies thai the contents Pile is available (i.e. a digital work corresponding to the request has been 
backed-up.) If It is not, it ends the transaction with an error. 

• The repositories perform the common opening transactkm steps. 

• The sewer retrieves the key from the restoiatton file. It decrypts the work contents, data, and usage rights. 

• The sender transmits the requested contents and data to the requester according to the transmission protocol. If 
25 a Ncxt-Sot-OI-Rights has been provided, those rights arc transmitted as the rights for the work. Othenvisc, a set 

of default rights for backup files of the original are transmitted by the sen/er. 

• The requester stores the digital work. 

• The repositories perform the common closing transaction steps. 

30 The Delete Transaction 

A Delete transactkm deletes a digital work or a number of copies of a digital work from a repository. Practtoally all 
digitsi works would have delete rights. 

3S » The requester sends the seiver a message to initiate a delete transaction. This message indicates the work to be 
deleted, Ihe versbn of the delete right for the tiansactnn. 

• The repositories perform the common opening transactton steps. 

• The server deletes the file, erasing it from the file system. 

• The repositories perform the common closing transaction steps. 

40 

The Directory Transaction 

A Directory transaction is a request (or infonnation about folders, digital works, and their parts. This amounts to 
roughly the same idea as protection codes in a convenOonal tile system like TENEX. except that it is generalized to 
the full power of the access specifications of the usage rghts language. 

The Directory transaction has the Important role of passing along descriptions of the rights and fees associated 
with a digital work. When a user wants to exercise a right, me user interface of his repository implicitly makes a directory 
request lo detennine the versions of the right that are available. Typically these are presented to the user - such as 
with different choices of billing for exercising a right. Thus, many directory transactions are invisible to the user and 
so are exercised as part of Ihe nonnal process of exercising all rights. 

• The requester sends the server a message to initiate a Directory transaction. This message indicates the file or 
folder that is the root of tho directory request and the version of the directory right used lor the transaction. 

• The sewer verifies that the information is accessible to Ihe requester. In particular, it does not return the names 
ss of any files that have a HIDE-NAME status in their directory specifications, and it does not return the parts of any 

folders or files that have HIDE-PARTS in their specification. If the information is not accessible, the server ends 
the transaction with an error. 

• The repositories perform the common opening transactnn steps. 



23 



EP 0 715 246 A1 



• The server sends the requested data to the requester according to the Iransmission protocol. 

• The requester records the data. 

• The repositories perform the common closing transaction steps. 

s The Fplder Transaction 

A Folder transaction is a request to create or rename a (older, or to move a work between folders. Together with 
Dlrectoiy rights, Folder rights control the degree to which organization of a repository can be accessed or modified 
from another repository. 

10 

• The requester sends the server a message to initiate a Folder transaction. This message indicates the (older that 
is the root ol the (older request, the version o( the tolder right tor the transaction, an operation, and data. The 
operation can be one of create, rename, and move file. The data are the specifications required for the operation, 
such as a specification of a (older or digital work and a name. 

75 • The repositories per(orm the common opening transaction steps. 

• The server performs the requested operation - creating a (older, renaming a (older, or moving a work between 
lolders. 

• The repositories perform the common closing transaction steps. 

20 The Extract Transaction 

A extract transaction is a request to copy a part of a digital work and to create a new work containing it. The 
extraction operation differs from copying in that it can be used to separate a part ol a digital work from d-blocks or 
shells that place additional restrictions or fees on it. The extraction opeialion differs from the edit operation in that it 
2S doGS not change the contents of a work, only its embedding in d-blocks. Extraction creates a now digital work. 

• The requester sends the server a message to initiate an Extract transaction. This message indicates the part of 
the work to be extracted, the version ol the extract right to be used in the transaction, the destination address 
information tor placing the part as a new work, the file data (or the work, and the number of copies involved. 

30 • The repositories per(onm the convnon opening transaction steps. 

• The sewer transmits the requested contents and data lo the requester according to the transmission protocol. I( 
a Next-Set-Of-Rights has been provided, those rights are Iransnnitted as the rights for the new work. Othenvlse, 
the rights of the original are transmitted. The Copy-Count field for this right is set tothe number-of-c<pies requested. 

• The requester records the contents, data, and usage rights and stores the work. It records the date and time that 
3s new work was made in the properties of the work. 

• The repositories pertorm the common closing transaction steps. 

The Embed Transaction 

40 An embed transaction is a request to make a digital work become a part o( another digital work or to add a shell 
d-block to enable the adding of fees by a distributor o( the work. 

• The requester sends the sen/er a message to initiate an Embed transaction. This message indicates Ihe work lo 
be embedded, the version of the embed right to be used in the transaction, the destination address information 
(or placing the part as a a work, the (ile data (or the work, and the number ol copies involved. 

• The sender checks the control specitR:atk}ns (or all ol the rights in the part and the destination. If they are Incom- 
patible, the sen/er ends the transaction with an error. 

• The repositories perform the common opening transactkMi steps. 

• The sen/er transmits the requested contents and data to the requester according to the transmission protocol. If 
so a Next-Set-OI-Rights has been provided, those rights are transmitted as the rights (or the new work. Othenwise, 

the rights of the original are transmitted. The Copy-Count (ield lor this right is set to the number-of-copies requested. 

• The requester records the contents, data, and usage rights and embeds the work in the destination file. 

• The reposKories pertorm the common closing transaction steps. 

ss The Edit Transaction 

An Edit transaction is a request to make a new digital work by copying, selecting and modifying portions of an 
existing digital work. This operatkm can actually change the contents o( a digital tvork. The kinds of changes that are 
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permilted depend on the process being used. Like the extraction operation, edit operates on portions of a digital ivork. 
In contrast with the extract operation, edit does not affect the rights or location of the woric II only changes the contents. 
The kinds of changes permitted are determined by the type specification of the processor specified in the rights. In the 
currently preferred embodiment, an edA transaction changes the work itself and does not make a new work. However, 
s It would be a reasonable variation to cause a new copy of the work to be made. 

• The requester sends the sewer a message to inKiate an Edit transaclion. This message indicates the work to be 
edited, the version of the edil right to be used in the transaction, the file data for the work (including its size), the 
process-ID for the process, and the number of copies Involved. 

10 'The server checks the compatibility of the process-ID to be used by the requester against any process-ID speci- 
(ication in the right. II they are incompatible, it ends the transaction with an error, 

• The repositories perform the common opening transacton steps. 

• The requester uses the process to change the contents of the digital work as desired. (For example, it can select 
and duplicate parts of it; combine it with other information', or compute (unctions based on the information. This 

>5 can amount to editing text, music, orplctures ortaking whatever othersteps are useful in creating a derivative work.) 

• The repositories perlorm the common closing transaction steps. 

The edit transaction Is used to cover a wide range of kinds of works. The category describes a process that takes 
as its Input any portion of a digital work and then modilies the input In some way For example, for text, a process lor 
20 editing the text would require edit rights. A process for 'summarizing* or counting words in the text would also be 
considered editing. For a music file, processing could involve changing the pitch or tempo, or adding reverberations, 
or any other audio effect. For digital video works, anything which alters the image would require edit rights. Examples 
would be colorizing, scaling, extracting still photos, selecting and combining Irames into story boards, sharpening with 
signal processing, and so on. 

2S Some creators may want to protect the authenticity of thoir works by limiting the kinds ol processes that can be 

performed on them. If there are no edit rights, then no processing is allowed atall. A processor kfentifier can be included 
to specify what kind of process Is allowed. If no process klentifier is specified, then arbitrary processors can be used. 
For an example of a specific process, a photographer may want to albw use of. his photograph but may not want it to 
be colorized. A mustelan may want to allow extraction of portions of his work but not changing of the tonality 

30 

Authorization Transactions 

There are many ways that authorization transactions can be defined. In the following, our preferred way Is to simply 
define them in terms of other transacttons that we already need (or repositories. Thus, it is convenient sometimes to 
3S speak of 'authorization transactions, ' but they are actually made up ol other transactions thai repositories already have. 

A usage right can specify an authorization-ID, which identifies an authorization object (a digital work in a file of a 
standard format) that the reposltoiy must have and which it must process. The authorization is given to the generic 
authorization (or ticket) server of the repository which begins to interpret the authorization. 

As described earlier, the authorization contains a senrer identifier, which may just be the generic authorization 
40 server or it may be another server. When a remote authorizatkxi senrer Is required, it must contain a digital address. 
It may also contain a digital certificate. 

II a remote authorization sen/er is required, then the authorization process first performs the following steps: 

• The generic authorization senrer attempts to set up the communications channel. (If the channel cannot be set 
IS up, (hen authorization fails with an error) 

• When the channel Is set up, it perfomis a registration process with the remote reposltoiy. (If registration fails, then 
the authorization fails with an error.) 

• When registration is complete, the generc authorization senrer invokes a. "Play" transaction with the remote re- 
pository, supplying the authorization document as the digital work to be played, and the remote authorizatbn sen/er 

so (a program) as the 'player.' (If the player cannot be found or has some other error, then the authorization fails with 
an error) 

• The authorization sorter then 'plays' the authorizatton. This involves decrypting it using either the public key of 
the master repository that issued the certificate or tho session key from the repository that transmitted it. The 
authorization server then performs various tests. These tests vary according to the authorization server. They 

ss include such steps as checking issue and validity dates of the authorization and checking any hot-lists of known 
Invalid authorizations. The authorization senrer may require carrying out any other transactions on the repository 
as well, such as checking directories, getting some person to supply a password, or playing some other digital 
work. It may also invoke some special process for checking Hiformaiion about locations or recent events. The 
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'script' for such steps is contained within the authorization sen/er. 

• If all of the required steps are completed satisfactorily, the authorisation seiver completes the transaction normally, 
signaling that authorization is granted. 

s The Install Transaction 

An Install transaction is a request to install a digital work as njnnable software on a repository. In a typical case, 
the requester repository is a rendering repository and the software would be a new kind or new version of a player. 
Also in a typical case, the software would be copied to file system of the requester repository before it is installed. 

JO 

• The requester sends Ihe server an Install message. This message indicates (he worl< to be installed, the version 
of the Install right being invoked, and the file data for the woric (including its size). 

• The repositories perfam the common opening transaction steps. 

• The requester extracts a copy of the digital certificate for the software. If the certificate cannot be found or the 
^s master repository for the certificate is not known to the requester, the transaction ends with an error. 

• The requester decrypts the digital certificate using the public key of the master repository, recording the identity 
of the supplier and creator, a key lor decrypting the software, the compaiibilliy information, and a tamper-checking 
code. (This step certilies the software.) 

• The requester decrypts Ihe software using the key from the certificate and computes a check code on it using a 
20 i-way hash luncifon. If Ihe check-code does not match Ihe tamper-checking code from the certificate, the instal- 
lation transactkn ends with an error. (This step assures that the contents of the software, including the vartous 
scripts, have not been tampered wllh.) 

• The requester retrieves the instructkins in the compatibility-checking script and foltows them. If the software is not 
compatible with the repository, the installation transaction ends with an error (This step checks platform compat- 

« ibility.) 

• The requester retrieves the instructions in the installation script and follows them. If there is an error in this process 
(such as insufficient resources), (hen the transactk)n ends with an error. Note that the installatbn process puts the 
njnnable software in a place in the repository where it is no longer accessble as a woric for exercising any usage 
rights other than the executnn of the software as part of repository operations in canying out other transactions. 

30 » The repositories perform the common ck>sing transaction Steps. 

The Uninslall Transaction 

An Uninstall transaction is a request to remove software from a repository. Since uncontrolled or incorrect removal 
3S of software from a repository could compromise its behavioral integrily, this step is controlled. 

• The requester sends the server an Uninstall message. This message indicates the work to be uninstalled. Ihe 
version of the Uninstall right being invoked, and the file data for the work (including its size). 

• The repositories perform Ihe common opening transactbn steps. 

10 • The requester extracts a copy of the digital certificate for the software. If the certificate cannot be found or the 
master repository for the certificate is not known to the requester, Ihe transaction ends with an error. 

• The requester checks whether the software is installed. If the software is not installed, the transaction ends with 
an error. 

• The requester decrypis the digital certificate using the public key of the master repository, recording the identity 
« of the supplier and creata. a key for decrypting the software, the compatibility infomnation, and a tamper-checking 

code. (This step authenticates the certification of the software, including the script for uninstalling it.) 

• The requester decrypts the software using the key from the certWcate and computes a check code on it using a 
1-way hash function. If the check-code does not match the tamper-checking code from the certificate, Ihe instal- 
lation transaction ends with an error. (This step assures that the contents of the software, including the various 

50 scripts, have not been tampered with.) 

• The requester retrieves the instructions in the uninstallation script and foflqws them. If there is an error in this 
process (such as insuffksienl resources), then the transaction ends with an error. 

• The repositories perform the common ctosing transaction steps. 

ss 

Claims 

1 . A method for controlling access to and distribution of a composite digital work, said composite digital work com- 
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prising a plurality of parts, said method comprising ttie steps o(: 

a) creating a composite digital worit; 

b) creating a description structure for said composite digital work, said description structure comprising a 
plurality of description blocks, each of said description btocks storing access information for at least one of 
said plurality ol parts of said composite digital work; 

c) storing said descripUon simcture and said composite digital work n a repository; 

d) saki reposiiory receiving a request to access said composite digital work, said request having one or more 
request attributes; and 

e) said repository determining if said request may be granted by examining the access information lor each 
description btock of said descriptfon structure of said composite digital work with respect to sakJ one or more 
request attributes of said request. 

The method as recited in Claim 1 wherein said step of creating a composite digital work is further comprised of 
the steps of: 

al ) creating a first part of said digital work; 

a2) creating a first description block for said first part of said composite digital work; 

a 3) obtaining an existing second part for said composite digital work, said second part of the digital work having 

a second description block: 

a4) combining sakI first part and said second part to form saki composite digital work; and 
a5) creating a third description block (or said composite digital work. 

The method as recited in Claim 2 wherein said step of creating a description structure for said composite digital 
work is further comprised of the step of linking said first dcscrf>tion block, said second description block and said 
third description block to correspond to the organizatton of saki composite digital work. 

The method as recited In Claim 3 wherein sakI step of storing sakI description stnjcture and said composite digital 
work in a repository is further comprised of the steps of skving said description structure in a first storage means 
and said composite digital work In a second stonage means. 

The method as recited in Claim 4 wherein each of sakJ first description block. sakI second description block and 
said third description block is comprised of a pointer to a corresponding part of said composite digital worii stored 
in said second storage means and a control inlomiation part tor storing usage rights for said corresponding part 
of said digital work and saki step of creating a first description bk>ck (or said first part o( sakI composite digital work 
is (urther comprised ol the step of specifying a (irst set of usage rights and storing in said control informatk>n part 
of said first description block. 

The method as recited in Claim 1 wherein said step o( creating a description structure for sakJ composite digital 
work is further comprised of the step of adding a shell descriptkm bk>ck (or specifying usage rights and fees of a 
distributor of said composite digital work. 

The method as recited in Claim 2 wherein said step of obtaining an existing second part (or said composite digital 
woric is (urther corrprised of the step o( extracting saM second part from an existing digital wori«. 

A repository tor storing and controlling access to composite digital works comprising: 

an interface means lor receiving requests to access digital works stored therein; 
a (irst storage unit for storing digital data representing digital works; 

a second storage unit (or storing description structures (or digital works stored in said (irst storage unit, sakJ 
description structure comprising a plurality of description blocks, each of sakI description blocks comprising: 
a pointer to a parent description block, one or more pointers to children description bkjcks, a pointer to a 
corresponding pan of a digital work stored in said first storage unit and a usage rights part for storing one or 
more usage rights, each of said usage rights specifying an instance of how said part may be used; 
a transactions processor for processing requests to access a digital work, said transactions processor com- 
prising a means (or klentifying a usage right (rem a request to access saU digital work, and a means (or 
determining if a description bkx:k contains an identified usage right. 
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9. The reposftoiy as recited in claim 8 wherein said transaction processor is further comprised ot usage rights conflict 
resolution means (or resolving usage rights conflicts between different description blocks. 

10. A system for controDing access to and usage o< composite digital works, said composite digital work comprising 
s a plurality ol digital works, said system comprising: 

means (or attaching usage rights to dgital works, said usage rights indicating how a recipient of a digital work 
may use and subsequently distrbute said digital work; 

means (or creating a description structure (or said composite digital work, said descriptbn structure comprising 
10 a description block for each digital work of said composite digital work, sakJ description block comprising said 

usage rights (or said digital work and addressing in(om>ation (or said digital work; 
a plurality o( repositories for managing exchange of dig'rtal works based on usage rights attached to said digital 
works, each otsak) plurality ot document repositories comprising a storage means (or storing digital works, a 
processor having a first sender mode o( operation (or processing access requests to said digital works and a 
IS second requester mode o( operatkxi for initiating requests to access digital works, a timekeeping means and 

a connectnn means; 

a rendering system tor rendering o( digital works, sakJ rendering system comprising a rendering repository (or 
secure receipt of composite digital works and a rendering devkse having means (or converting digital signals 
to signals suitable (or rendering ot said digital works. 
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rSOy-— DigitaIWorkRight8:= (Rights*) 

1S02 — Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec } 
{Access-Spec} {Fee-Spec}) 
1503 — -Right-Code := Render-Code | Tranaport-Code I File-Management- 
Codel Derivative-Works- Code |Configuration-0)de 
1504 — Render-Code := [ Play : {Player: Player-ID} | Print: {IVinter; Printer-ID}] 
7505-— Transport-Code : = [Copy | Transfer | Loan {Remaining-Rights: 

Next-Set-of-Rights}]{(Next-Copy-Rights:Next-Set-of-Rights)} 
1SQ6 — ^File-Managemcnt-Code := Backup {Back-Up-Copy-Rights: 

Nert-Set-of-Rights} | Restore I Delete | Folder 
I Directory {Name: Hide-Local | Hide-Remote} 
{Parts: Hide-Local i Hide-Remote} 

1507 — ^Derivative-Works-Code : = (Extract | Embed | Bdit{Process: 

Process-ID}] {Nezt-Copy-Rights : 
Nezt-Set-ofRights} 

1508 — Configuration-Code := Install i Uninstall 
7509--N«xt-SemMUght«:= {(Add: Set-Of-Rights)} {(Delete: 

Set-Of-Rights)} {(RepUce: Set-Of-Rights )K(Keep: Set-Of-Rights )} 
f 5f 0 ^Copy-Count : = (Copie8:po8itive-integer 1 0 1 Unlimited) 
1S1 1 — Control-Spec := (Control: {Restrictable | Unrestrictablo} 

{Unchargeable I Chargeable}) 
T572'^Time-Spec := ({Fixed-Interval | Sliding-Interval | Meter-Time} 
Until: Expiration-Date) 
7573^ — ■ Fixed-Interval : = From: Start-Time 
7574'^Sliding-Interval:= Interval: Use-Duration 
f575~-Meter-Time:= Time-Remaining: Remaining-Use 
7576 — ■ Access-Spec : = ({SC: Security-Class} {Authorization: Authorization-ID*} 

{Other-Authorization: Authorization-ID*} {Ticket: Ticket-ID}) 
7577^ — Fee-Spec: {Scheduled-Diacount} Regular-Fee-Spec |Scheduled-Fee-Spec | 
Markup-Spec 

1518 — Schedttled-Discount:= Scheduled-Diacount: (Scheduled-Discount: 

(Time-Spec Percentage]*) 
^579^ — ^Regular-Fee-Spec:= ({Fee: | Incentive:} [Per-Use-Spec | Metered-Rate- 
Spec I Best-Price-Spec | Call-For-Price-Spec] 
{Min: Money-Unit Per: Tim&-Spec}{Maz: 
Money-Unit Per. Time-Spec} To: Aeeount-ID) 
7520 — ^Per-Use-Spec = Per-Use: Money-unit 
1527 '^Metered-Rate-Spec : - Metered: Money-Unit Per: Time-Spec 
7S22 — 'Best-Priee-Spec := Best-Price: Money-unit Max: Money-unit 
1523 — Call-For^Price-Spec := Call-For -Price 
1524'^ Scheduled-Fee-Spee:= (Schedule: (Time-Spec Regular-Fee-Spec)" ) 
7525'wMarkup-Spee: = Markup: percentage To: Account-ID 

Fig.1S 
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